[PATCH] D134057: [clang][Interp] Start implementing record types

2022-09-19 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder updated this revision to Diff 461148.
tbaeder marked 2 inline comments as done.

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

https://reviews.llvm.org/D134057

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/ByteCodeExprGen.h
  clang/lib/AST/Interp/ByteCodeStmtGen.cpp
  clang/lib/AST/Interp/Interp.h
  clang/lib/AST/Interp/Record.h
  clang/test/AST/Interp/records.cpp
  clang/test/AST/Interp/references.cpp

Index: clang/test/AST/Interp/references.cpp
===
--- clang/test/AST/Interp/references.cpp
+++ clang/test/AST/Interp/references.cpp
@@ -83,9 +83,9 @@
   S s{1, 2};
 
   int &j = s.i;
-  j += 10;
+  j = j + 10;
 
   return j;
 }
 // FIXME: Should be accepted.
-static_assert(RefToMemberExpr() == 11, ""); // expected-error {{not an integral constant expression}}
+static_assert(RefToMemberExpr() == 11, "");
Index: clang/test/AST/Interp/records.cpp
===
--- /dev/null
+++ clang/test/AST/Interp/records.cpp
@@ -0,0 +1,104 @@
+// RUN: %clang_cc1 -fexperimental-new-constant-interpreter -verify %s
+// RUN: %clang_cc1 -verify=ref %s
+
+// ref-no-diagnostics
+// expected-no-diagnostics
+
+struct BoolPair {
+  bool first;
+  bool second;
+};
+
+struct Ints {
+  int a = 20;
+  int b = 30;
+  bool c = true;
+  // BoolPair bp = {true, false}; FIXME
+
+  static const int five = 5;
+  static constexpr int getFive() {
+return five;
+  }
+
+  constexpr int getTen() const {
+return 10;
+  }
+};
+
+constexpr Ints getInts() {
+  return {64, 128, true};
+}
+
+static_assert(Ints::getFive() == 5, "");
+
+constexpr Ints ints;
+static_assert(ints.a == 20, "");
+static_assert(ints.b == 30, "");
+static_assert(ints.c, "");
+static_assert(ints.getTen() == 10, "");
+
+constexpr Ints ints2{-20, -30, false};
+static_assert(ints2.a == -20, "");
+static_assert(ints2.b == -30, "");
+static_assert(!ints2.c, "");
+
+constexpr Ints ints3 = getInts();
+static_assert(ints3.a == 64, "");
+static_assert(ints3.b == 128, "");
+static_assert(ints3.c, "");
+
+constexpr Ints ints4 = {
+  .a = 40 * 50,
+  .b = 0,
+  .c = (ints.a > 0),
+
+};
+static_assert(ints4.a == (40 * 50), "");
+static_assert(ints4.b == 0, "");
+static_assert(ints4.c, "");
+
+
+// FIXME: Implement initialization by DeclRefExpr.
+//constexpr Ints ints4 = ints3;  TODO
+
+
+
+struct Ints2 {
+  int a = 10;
+  int b;
+};
+// FIXME: Broken in the new constant interpreter.
+//   Should be rejected, but without asan errors.
+//constexpr Ints2 ints2;
+
+class C {
+  public:
+int a;
+int b;
+
+  constexpr C() : a(100), b(200) {}
+};
+
+constexpr C c;
+static_assert(c.a == 100, "");
+static_assert(c.b == 200, "");
+
+constexpr int getB() {
+  C c;
+  int &j = c.b;
+
+  j = j * 2;
+
+  return c.b;
+}
+static_assert(getB() == 400, "");
+
+constexpr int getA(const C &c) {
+  return c.a;
+}
+static_assert(getA(c) == 100, "");
+
+constexpr const C* getPointer() {
+  return &c;
+}
+static_assert(getPointer()->a == 100, "");
Index: clang/lib/AST/Interp/Record.h
===
--- clang/lib/AST/Interp/Record.h
+++ clang/lib/AST/Interp/Record.h
@@ -67,6 +67,7 @@
   }
 
   unsigned getNumFields() const { return Fields.size(); }
+  const Field *getField(unsigned I) const { return &Fields[I]; }
   Field *getField(unsigned I) { return &Fields[I]; }
 
   using const_base_iter = BaseList::const_iterator;
Index: clang/lib/AST/Interp/Interp.h
===
--- clang/lib/AST/Interp/Interp.h
+++ clang/lib/AST/Interp/Interp.h
@@ -492,6 +492,9 @@
   return true;
 }
 
+/// 1) Pops the value from the stack
+/// 2) Pops a pointer from the stack
+/// 3) Writes the value to field I of the pointer
 template ::T>
 bool InitField(InterpState &S, CodePtr OpPC, uint32_t I) {
   const T &Value = S.Stk.pop();
Index: clang/lib/AST/Interp/ByteCodeStmtGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeStmtGen.cpp
+++ clang/lib/AST/Interp/ByteCodeStmtGen.cpp
@@ -94,10 +94,6 @@
   // Classify the return type.
   ReturnType = this->classify(F->getReturnType());
 
-  // Set up fields and context if a constructor.
-  if (auto *MD = dyn_cast(F))
-return this->bail(MD);
-
   if (auto *Body = F->getBody())
 if (!visitStmt(Body))
   return false;
Index: clang/lib/AST/Interp/ByteCodeExprGen.h
===
--- clang/lib/AST/Interp/ByteCodeExprGen.h
+++ clang/lib/AST/Interp/ByteCodeExprGen.h
@@ -71,6 +71,7 @@
   bool VisitBinaryOperator(const BinaryOperator *E);
   bool VisitCXXDefaultArgExpr(const CXXDefaultArgExpr *E);
   bool VisitCallExpr(const CallExpr *E);
+  bool VisitCXXDefaultInitExpr(const CXXDefaultInitExpr *E);
   bool VisitCXXBoolLiteralExpr(const CXXBoolLiteralExpr *E);
   bool VisitCXXNullPtrLiteralExpr(cons

[PATCH] D133983: [HLSL] Add SV_DispatchThreadID

2022-09-19 Thread Xiang Li via Phabricator via cfe-commits
python3kgae updated this revision to Diff 461151.
python3kgae added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133983

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CGHLSLRuntime.cpp
  clang/lib/CodeGen/CGHLSLRuntime.h
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGenHLSL/semantics/DispatchThreadID.hlsl
  clang/test/SemaHLSL/Semantics/entry_parameter.hlsl

Index: clang/test/SemaHLSL/Semantics/entry_parameter.hlsl
===
--- clang/test/SemaHLSL/Semantics/entry_parameter.hlsl
+++ clang/test/SemaHLSL/Semantics/entry_parameter.hlsl
@@ -2,9 +2,12 @@
 // RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-mesh -x hlsl -ast-dump -verify -o - %s 
 
 [numthreads(8,8, 1)]
-// expected-error@+1 {{attribute 'SV_GroupIndex' is unsupported in Mesh shaders, requires Compute}}
-void CSMain(int GI : SV_GroupIndex) {
-// CHECK: FunctionDecl 0x{{[0-9a-fA-F]+}} <{{.*}}> line:[[@LINE-1]]:6 CSMain 'void (int)'
+// expected-error@+2 {{attribute 'SV_GroupIndex' is unsupported in Mesh shaders, requires Compute}}
+// expected-error@+1 {{attribute 'SV_DispatchThreadID' is unsupported in Mesh shaders, requires Compute}}
+void CSMain(int GI : SV_GroupIndex, int ID : SV_DispatchThreadID) {
+// CHECK: FunctionDecl 0x{{[0-9a-fA-F]+}} <{{.*}}> line:[[@LINE-1]]:6 CSMain 'void (int, int)'
 // CHECK-NEXT: ParmVarDecl 0x{{[0-9a-fA-F]+}} <{{.*}}> col:17 GI 'int'
 // CHECK-NEXT: HLSLSV_GroupIndexAttr
+// CHECK-NEXT: ParmVarDecl 0x{{[0-9a-fA-F]+}} <{{.*}}> col:41 ID 'int'
+// CHECK-NEXT: HLSLSV_DispatchThreadIDAttr
 }
Index: clang/test/CodeGenHLSL/semantics/DispatchThreadID.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/semantics/DispatchThreadID.hlsl
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -emit-llvm -finclude-default-header -disable-llvm-passes -o - %s
+
+// Make sure SV_DispatchThreadID translated into dx.thread.id.
+
+const RWBuffer In;
+RWBuffer Out;
+
+// CHECK: define void @foo()
+// CHECK: call i32 @llvm.dx.thread.id(i32 0)
+// CHECK: call void @"?foo@@YAXH@Z"(i32 %{{.*}})
+[shader("compute")]
+[numthreads(8,8,1)]
+void foo(int Idx : SV_DispatchThreadID) {
+  Out[Idx] = In[Idx];
+}
+
+// CHECK: define void @bar()
+// CHECK: call i32 @llvm.dx.thread.id(i32 0)
+// CHECK: call i32 @llvm.dx.thread.id(i32 1)
+// CHECK: call void @"?bar@@YAXT?$__vector@H$01@__clang@@@Z"(<2 x i32> %{{.*}})
+[shader("compute")]
+[numthreads(8,8,1)]
+void bar(int2 Idx : SV_DispatchThreadID) {
+  Out[Idx.y] = In[Idx.x];
+}
+
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -6907,6 +6907,25 @@
   D->addAttr(::new (S.Context) HLSLSV_GroupIndexAttr(S.Context, AL));
 }
 
+static void handleHLSLSV_DispatchThreadIDAttr(Sema &S, Decl *D,
+  const ParsedAttr &AL) {
+  using llvm::Triple;
+  Triple Target = S.Context.getTargetInfo().getTriple();
+  // FIXME: it is OK for a compute shader entry and pixel shader entry live in
+  // same HLSL file.
+  if (Target.getEnvironment() != Triple::Compute &&
+  Target.getEnvironment() != Triple::Library) {
+uint32_t Pipeline =
+(uint32_t)S.Context.getTargetInfo().getTriple().getEnvironment() -
+(uint32_t)llvm::Triple::Pixel;
+S.Diag(AL.getLoc(), diag::err_hlsl_attr_unsupported_in_stage)
+<< AL << Pipeline << "Compute";
+return;
+  }
+
+  D->addAttr(::new (S.Context) HLSLSV_DispatchThreadIDAttr(S.Context, AL));
+}
+
 static void handleHLSLShaderAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
   StringRef Str;
   SourceLocation ArgLoc;
@@ -8920,6 +8939,9 @@
   case ParsedAttr::AT_HLSLSV_GroupIndex:
 handleHLSLSVGroupIndexAttr(S, D, AL);
 break;
+  case ParsedAttr::AT_HLSLSV_DispatchThreadID:
+handleHLSLSV_DispatchThreadIDAttr(S, D, AL);
+break;
   case ParsedAttr::AT_HLSLShader:
 handleHLSLShaderAttr(S, D, AL);
 break;
Index: clang/lib/CodeGen/CGHLSLRuntime.h
===
--- clang/lib/CodeGen/CGHLSLRuntime.h
+++ clang/lib/CodeGen/CGHLSLRuntime.h
@@ -39,7 +39,8 @@
   uint32_t ResourceCounters[static_cast(
   hlsl::ResourceClass::NumClasses)] = {0};
 
-  llvm::Value *emitInputSemantic(llvm::IRBuilder<> &B, const ParmVarDecl &D);
+  llvm::Value *emitInputSemantic(llvm::IRBuilder<> &B, const ParmVarDecl &D,
+ llvm::Type *Ty);
 
 public:
   CGHLSLRuntime(CodeGenModule &CGM) : CGM(CGM) {}
Index: clang/lib/CodeGen/CGHLSLRuntime.cpp
===
--- clang/lib/CodeGen/CGHLSLRuntime.cpp
+++ clang/lib/CodeGen/CGHLSLRuntime.cpp
@@ -109

[PATCH] D134057: [clang][Interp] Start implementing record types

2022-09-19 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added inline comments.



Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:673
+  if (Optional T = classify(Init->getType())) {
+if (!this->emitDupPtr(Initializer))
+  return false;

shafik wrote:
> This section of code looks duplicated w/ the above, can it be factored out or 
> will they diverge as you fill in more details?
The version above will go away in my next patch to record implementation.



Comment at: clang/test/AST/Interp/records.cpp:7
+
+struct Ints {
+  int a = 20;

shafik wrote:
> How about also have a field that is a struct and initializing that.
> 
> Also using initializer lists in in class member initializers and also 
> designated initializers as well. 
> 
> I am not sure if unions works yet but anon union members as well.
Struct initializers here aren't supported yet (that's what the "Handle 
initializer for non-primitive values" assert in `VisitRecordInitializer` is 
about). I added a FIXME comment and a test for designated initializers.


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

https://reviews.llvm.org/D134057

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


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

2022-09-19 Thread Paulo Matos via Phabricator via cfe-commits
pmatos marked 3 inline comments as done.
pmatos added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:7332
+def err_attribute_webassembly_funcref : Error<
+  "'__clang_webassembly_funcref' attribute can only be applied to function 
pointer types">;
 

aaron.ballman wrote:
> 1) What is `__clang_webassembly_funcref`? Did you mean `__funcref`?
> 2) There's no test coverage for this diagnostic.
> 1) What is `__clang_webassembly_funcref`? Did you mean `__funcref`?
> 2) There's no test coverage for this diagnostic.

Yes, I meant __funcref. Thanks, will add test coverage for the diagnostic.



Comment at: clang/include/clang/Basic/TokenKinds.def:666
+// WebAssembly Type Extension
+KEYWORD(__funcref , KEYALL)
+

aaron.ballman wrote:
> Why is this a keyword in all language modes?
I might have misread the docs but this keyword should be available for both C 
and C++. Maybe I want `KEYC99 | KEYCXX` ?



Comment at: clang/include/clang/Sema/Sema.h:13103-13104
  CallExpr *TheCall);
+  bool CheckWebAssemblyBuiltinFunctionCall(const TargetInfo &TI, unsigned 
BuiltinID,
+ CallExpr *TheCall);
 

aaron.ballman wrote:
> Formatting is off here.
Don't understand why. It's the same as `CheckRISCVBuiltinFunctionCall` ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128440

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


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

2022-09-19 Thread Paulo Matos via Phabricator via cfe-commits
pmatos updated this revision to Diff 461159.
pmatos added a comment.

Addressed some of the concerns from the comments but not ready for review yet.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128440

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

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

[PATCH] D134137: [clangd] Return earlier when snippet is empty

2022-09-19 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added inline comments.



Comment at: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp:1017
 
+TEST(CompletionTests, EmptySnippetDoesNotCrash) {
+// See https://github.com/clangd/clangd/issues/1216

Does this test trigger the crash for you when run without the fix?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134137

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


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

2022-09-19 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added a comment.

In D130181#3769618 , @njames93 wrote:

> In D130181#3769083 , @JonasToth 
> wrote:
>
>> ...
>
> Your concerns aren't actually that important. Because the transformations 
> only work on for binary operators, and not CXXOperatorCallExpr, it would 
> always never do any special logic, instead just wrap the whole thing in 
> parens and negate it.

Ah yes, you are right! That makes it very much better.

> I think the best way to resolve that could be delayed diagnostics for 
> template operators.
> So cache the locations of all dependent binary (and unary) operators, and see 
> if any of them either stay as binary operators or get transformed into 
> CXXOperatorCallExprs, if so don't emit the fix.
> The second option is to just not emit any fix for template dependent 
> operators.
> WDYT?

I am not 100% sure that delayed diagnostics would solve the issue _always_

  template 
  bool type_dependent_logic(T1 foo, T2 bar) {
  return foo && !bar;
  }

This template would be a counter example to yours, where I feel less 
comfortable.
The definition itself has `BinaryOperator` in the AST.

Now different TUs might use this template wildly different, e.g. TU1.cpp only 
with builtins, making a transformation possible and TU2.cpp with fancy and 
weird types making the transformation not possible.

clang-tidy (e.g. with `run-clang-tidy`) would now still change the template 
definition after it received the diagnostic from TU1.cpp, even though in 
TU2.cpp it is not considered as valid.
This issue is common to many checks, e.g. the `const-correctness` suffered from 
it as well. In the `const` case I had to just had to consider type dependent 
expressions as modifications.

For TU-local templates your strategy is certainly viable. But in the general 
case I would rather not do it, or at least have a "default-off" option for it.

Finally, what are your thoughts on `optional` types? They are kinda `bool` in 
the sense of this check, but suffer from the shortcomings with overloaded 
operators.
Should they be explicitly not considered now (i am fine with that!)? In that 
case, it should be mentioned as limitation in the documentation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130181

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


[PATCH] D106577: [clang] Define __STDC_ISO_10646__

2022-09-19 Thread Michał Górny via Phabricator via cfe-commits
mgorny added a comment.

In D106577#2965059 , @aaron.ballman 
wrote:

> Thanks! I've passed them along to WG14 and will report back what I hear.

Have you heard anything since?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106577

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


[PATCH] D134137: [clangd] Return earlier when snippet is empty

2022-09-19 Thread Tom Praschan via Phabricator via cfe-commits
tom-anders marked an inline comment as done.
tom-anders added inline comments.



Comment at: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp:1017
 
+TEST(CompletionTests, EmptySnippetDoesNotCrash) {
+// See https://github.com/clangd/clangd/issues/1216

nridge wrote:
> Does this test trigger the crash for you when run without the fix?
Yes it does, I double checked. Not sure why it didn't work for you


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134137

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


[PATCH] D134137: [clangd] Return earlier when snippet is empty

2022-09-19 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp:1017
 
+TEST(CompletionTests, EmptySnippetDoesNotCrash) {
+// See https://github.com/clangd/clangd/issues/1216

tom-anders wrote:
> nridge wrote:
> > Does this test trigger the crash for you when run without the fix?
> Yes it does, I double checked. Not sure why it didn't work for you
it doesn't trigger the crash for me either.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134137

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


[PATCH] D109621: [clang] [Driver] Fall back to default.cfg when calling clang w/o prefix

2022-09-19 Thread Serge Pavlov via Phabricator via cfe-commits
sepavloff added inline comments.



Comment at: clang/docs/UsersManual.rst:915
+in the directory where Clang resides. If Clang is started via an executable
+without target prefix, Clang will use ``default.cfg`` instead.
 

What about using default config based on driver mode (clang.cfg, gcc.cfg etc)? 
It looks like a more flexible solution, - different driver modes may need 
different default settings. Even if these setting are identical, the default 
config files may be links to one, say `clang.cfg` or just include that file 
with `@file`.


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] D109621: [clang] [Driver] Fall back to default.cfg when calling clang w/o prefix

2022-09-19 Thread Michał Górny via Phabricator via cfe-commits
mgorny added inline comments.



Comment at: clang/docs/UsersManual.rst:915
+in the directory where Clang resides. If Clang is started via an executable
+without target prefix, Clang will use ``default.cfg`` instead.
 

sepavloff wrote:
> What about using default config based on driver mode (clang.cfg, gcc.cfg 
> etc)? It looks like a more flexible solution, - different driver modes may 
> need different default settings. Even if these setting are identical, the 
> default config files may be links to one, say `clang.cfg` or just include 
> that file with `@file`.
It's actually described below — you can have `default-clang.cfg`, 
`default-clang++.cfg`, etc. Using this naming makes it possible to use the same 
logic for default as for prefixed execs.


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] D109621: [clang] [Driver] Fall back to default.cfg when calling clang w/o prefix

2022-09-19 Thread Serge Pavlov via Phabricator via cfe-commits
sepavloff added a comment.

In D109621#3791511 , @mstorsjo wrote:

> On this topic, it would be great if we could pick up a per-target default 
> config file too, if clang is invoked with `clang -target `. Currently 
> this is done automatically if clang is invoked as `-clang`, but not 
> with an explicit `-target` parameter.

Would enabling config files in such invocations be a solution for your use case?


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] D109621: [clang] [Driver] Fall back to default.cfg when calling clang w/o prefix

2022-09-19 Thread Michał Górny via Phabricator via cfe-commits
mgorny added a comment.

In D109621#3799133 , @sepavloff wrote:

> In D109621#3791511 , @mstorsjo 
> wrote:
>
>> On this topic, it would be great if we could pick up a per-target default 
>> config file too, if clang is invoked with `clang -target `. 
>> Currently this is done automatically if clang is invoked as 
>> `-clang`, but not with an explicit `-target` parameter.
>
> Would enabling config files in such invocations be a solution for your use 
> case?

Not really, we don't strictly need per-target config files at the moment. There 
might be some use for them in the future but right now our most dire need is to 
be able to ensure that our config file is included in all invocations (except 
for explicit `--no-default-config`).

With this patch, this is handled by having files for all installed prefixes + 
`default*` for unprefixed executables.

I suppose an alternative option would be to do a major refactoring to support a 
wider range of naming variants with fallbacks. Would you prefer if I tried to 
do that?


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] D134137: [clangd] Return earlier when snippet is empty

2022-09-19 Thread Tom Praschan via Phabricator via cfe-commits
tom-anders marked an inline comment as done.
tom-anders added inline comments.



Comment at: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp:1017
 
+TEST(CompletionTests, EmptySnippetDoesNotCrash) {
+// See https://github.com/clangd/clangd/issues/1216

kadircet wrote:
> tom-anders wrote:
> > nridge wrote:
> > > Does this test trigger the crash for you when run without the fix?
> > Yes it does, I double checked. Not sure why it didn't work for you
> it doesn't trigger the crash for me either.
Huh, maybe this is a b



Comment at: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp:1017
 
+TEST(CompletionTests, EmptySnippetDoesNotCrash) {
+// See https://github.com/clangd/clangd/issues/1216

tom-anders wrote:
> kadircet wrote:
> > tom-anders wrote:
> > > nridge wrote:
> > > > Does this test trigger the crash for you when run without the fix?
> > > Yes it does, I double checked. Not sure why it didn't work for you
> > it doesn't trigger the crash for me either.
> Huh, maybe this is a b
Hmm could be a build type thing? I ran the tests for a Debug build, maybe it's 
different in Release?

Maybe we could also ask the author of the GitHub issue to check if it fixes the 
crash for them?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134137

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


[PATCH] D106577: [clang] Define __STDC_ISO_10646__

2022-09-19 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D106577#3799067 , @mgorny wrote:

> In D106577#2965059 , @aaron.ballman 
> wrote:
>
>> Thanks! I've passed them along to WG14 and will report back what I hear.
>
> Have you heard anything since?

Sorry, thanks for re-pinging this, it fell off my radar. Yes, I have heard back 
from WG14 but there was not really a consensus position (which means we'd need 
to write a paper if we want a more detailed answer from the committee). The 
direction things seemed to be heading, but we did not confirm, is that the 
library impacts the value of `__STDC_ISO_10646__` and so we don't have a way to 
set what this should expand to within the compiler.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106577

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


[PATCH] D106577: [clang] Define __STDC_ISO_10646__

2022-09-19 Thread Michał Górny via Phabricator via cfe-commits
mgorny added a comment.

In D106577#3799276 , @aaron.ballman 
wrote:

> Sorry, thanks for re-pinging this, it fell off my radar. Yes, I have heard 
> back from WG14 but there was not really a consensus position (which means 
> we'd need to write a paper if we want a more detailed answer from the 
> committee). The direction things seemed to be heading, but we did not 
> confirm, is that the library impacts the value of `__STDC_ISO_10646__` and so 
> we don't have a way to set what this should expand to within the compiler.

Thanks. I suppose we're back to `` and D34158 
 (-ish) then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106577

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


[PATCH] D134175: [clang][Interp] Implement record instance functions and returning struct types

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

Continuation of https://reviews.llvm.org/D134057. Implement passing a `This` 
pointer to instance functions as well as handling the RVO pointer. For the 
latter, I'm sure there are a lot of details left, but for now this works pretty 
well.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134175

Files:
  clang/lib/AST/Interp/ByteCodeEmitter.cpp
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/ByteCodeExprGen.h
  clang/lib/AST/Interp/ByteCodeStmtGen.cpp
  clang/lib/AST/Interp/Disasm.cpp
  clang/lib/AST/Interp/EvalEmitter.cpp
  clang/lib/AST/Interp/Function.cpp
  clang/lib/AST/Interp/Function.h
  clang/lib/AST/Interp/Interp.cpp
  clang/lib/AST/Interp/InterpFrame.cpp
  clang/lib/AST/Interp/InterpFrame.h
  clang/lib/AST/Interp/Pointer.h
  clang/test/AST/Interp/records.cpp

Index: clang/test/AST/Interp/records.cpp
===
--- clang/test/AST/Interp/records.cpp
+++ clang/test/AST/Interp/records.cpp
@@ -102,3 +102,24 @@
   return &c;
 }
 static_assert(getPointer()->a == 100, "");
+
+constexpr C RVOAndParams(const C *c) {
+  return C();
+}
+constexpr C RVOAndParamsResult = RVOAndParams(&c);
+
+constexpr int locals() {
+  C c;
+  c.a = 10;
+
+  // Assignment, not an initializer.
+  // c = C(); FIXME
+  c.a = 10;
+
+
+  // Assignment, not an initializer.
+  //c = RVOAndParams(&c); FIXME
+
+  return c.a;
+}
+static_assert(locals() == 10, "");
Index: clang/lib/AST/Interp/Pointer.h
===
--- clang/lib/AST/Interp/Pointer.h
+++ clang/lib/AST/Interp/Pointer.h
@@ -47,6 +47,7 @@
 
   void operator=(const Pointer &P);
   void operator=(Pointer &&P);
+  bool operator==(const Pointer &RHS) const { return Pointee == RHS.Pointee; }
 
   /// Converts the pointer to an APValue.
   APValue toAPValue() const;
@@ -317,7 +318,7 @@
 
   /// Prints the pointer.
   void print(llvm::raw_ostream &OS) const {
-OS << "{" << Base << ", " << Offset << ", ";
+OS << (void *)Pointee << "{" << Base << ", " << Offset << ", ";
 if (Pointee)
   OS << Pointee->getSize();
 else
Index: clang/lib/AST/Interp/InterpFrame.h
===
--- clang/lib/AST/Interp/InterpFrame.h
+++ clang/lib/AST/Interp/InterpFrame.h
@@ -35,6 +35,11 @@
   InterpFrame(InterpState &S, Function *Func, InterpFrame *Caller,
   CodePtr RetPC, Pointer &&This);
 
+  /// Creates a new frame with the values that make sense.
+  /// I.e., the caller is the current frame of S,
+  /// and the This() pointer is the current Pointer on the top of S's stack,
+  InterpFrame(InterpState &S, Function *Func, CodePtr RetPC);
+
   /// Destroys the frame, killing all live pointers to stack slots.
   ~InterpFrame();
 
Index: clang/lib/AST/Interp/InterpFrame.cpp
===
--- clang/lib/AST/Interp/InterpFrame.cpp
+++ clang/lib/AST/Interp/InterpFrame.cpp
@@ -36,6 +36,36 @@
   }
 }
 
+InterpFrame::InterpFrame(InterpState &S, Function *Func, CodePtr RetPC)
+: Caller(S.Current), S(S), Func(Func), RetPC(RetPC),
+  ArgSize(Func ? Func->getArgSize() : 0),
+  Args(static_cast(S.Stk.top())), FrameOffset(S.Stk.size()) {
+  assert(Func);
+
+  // As per our calling convention, the this pointer is
+  // part of the ArgSize.
+  // If the function has RVO, the RVO pointer is first.
+  // If the fuction has a This pointer, that one is next.
+  // Then follow the actual arguments (but those are handled
+  // in getParamPointer()).
+  if (Func->hasThisPointer()) {
+if (Func->hasRVO())
+  This = stackRef(sizeof(Pointer));
+else
+  This = stackRef(0);
+  }
+
+  if (unsigned FrameSize = Func->getFrameSize()) {
+Locals = std::make_unique(FrameSize);
+for (auto &Scope : Func->scopes()) {
+  for (auto &Local : Scope.locals()) {
+Block *B = new (localBlock(Local.Offset)) Block(Local.Desc);
+B->invokeCtor();
+  }
+}
+  }
+}
+
 InterpFrame::~InterpFrame() {
   if (Func && Func->isConstructor() && This.isBaseClass())
 This.initialize();
Index: clang/lib/AST/Interp/Interp.cpp
===
--- clang/lib/AST/Interp/Interp.cpp
+++ clang/lib/AST/Interp/Interp.cpp
@@ -55,8 +55,7 @@
 
 template ::T>
 static bool Call(InterpState &S, CodePtr &PC, const Function *Func) {
-  S.Current =
-  new InterpFrame(S, const_cast(Func), S.Current, PC, {});
+  S.Current = new InterpFrame(S, const_cast(Func), PC);
   APValue CallResult;
   // Note that we cannot assert(CallResult.hasValue()) here since
   // Ret() above only sets the APValue if the curent frame doesn't
@@ -66,8 +65,7 @@
 
 s

[clang] f51789c - Fix a typo in the release notes; NFC

2022-09-19 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2022-09-19T07:37:41-04:00
New Revision: f51789ce5e759b68584fe6c04a31930496bd6a41

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

LOG: Fix a typo in the release notes; NFC

Added: 


Modified: 
clang/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 035536d18d9b8..2546142d2b3d7 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -273,8 +273,7 @@ C2x Feature Support
 - Implemented `WG14 N2662 
`_,
   so the [[maybe_unused]] attribute may be applied to a label to silence an
   ``-Wunused-label`` warning.
-
-- Implemented `WG14 N508 
`_,
+- Implemented `WG14 N2508 
`_,
   so labels can placed everywhere inside a compound statement.
 
 C++ Language Changes in Clang



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


[clang] a244194 - Add additional test coverage for C2x N2508

2022-09-19 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2022-09-19T07:52:07-04:00
New Revision: a244194f73788de6dfd6d753ff09be3625613f9f

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

LOG: Add additional test coverage for C2x N2508

This spotted a mistake with the original patch, so it puts the status
back to "partial" in the C status tracking page.

This amends 510383626fe146e49ae5fa036638e543ce71e5d9.

Added: 
clang/test/C/C2x/n2508.c

Modified: 
clang/www/c_status.html

Removed: 




diff  --git a/clang/test/C/C2x/n2508.c b/clang/test/C/C2x/n2508.c
new file mode 100644
index 0..1610d6e17220d
--- /dev/null
+++ b/clang/test/C/C2x/n2508.c
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -verify -std=c2x %s
+
+/* WG14 N2508: partial
+ * Free positioning of labels inside compound statements
+ */
+void test() {
+  {
+  inner:
+  }
+
+  switch (1) {
+  // FIXME: this should be accepted per C2x 6.8.2p2.
+  case 1: // expected-error {{label at end of switch compound statement: 
expected statement}}
+  }
+
+  {
+  multiple: labels: on: a: line:
+  }
+
+final:
+}
+

diff  --git a/clang/www/c_status.html b/clang/www/c_status.html
index 395bdf5d22da9..f3e0ab6171a17 100644
--- a/clang/www/c_status.html
+++ b/clang/www/c_status.html
@@ -763,7 +763,13 @@ C2x implementation status
 
   Free positioning of labels inside compound statements
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2508.pdf";>N2508
-  Clang 16
+
+  Partial
+Clang supports labels at the end of compound statements but does
+not yet support case or default labels at
+the end of a switch statement's compound block.
+  
+
 
 
   Clarification request for C17 example of undefined behavior



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


[PATCH] D133887: [Clang] Support label at end of compound statement

2022-09-19 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Thank you for working on this! I spotted an issue where we're not quite 
complete with this implementation work. I pushed up a new test case in 
https://github.com/llvm/llvm-project/commit/a244194f73788de6dfd6d753ff09be3625613f9f
 that shows it (and set the C status page back to Partial in case this takes a 
while to address), but `case` and `default` labels should be accepted the same 
as any other label at the end of a compound statement.

Btw, when working on C standards features, I've started adding test coverage 
that demonstrates we fully implement the paper into the `clang/test/C/` 
directory, under the correct standard version. This helps us to track the 
status of proposals a bit more easily within the code base.




Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:298-299
   "and have an empty entry in the selector">;
-def err_label_end_of_compound_statement : Error<
-  "label at end of compound statement: expected statement">;
+def err_switch_label_end_of_compound_statement : Error<
+  "label at end of switch compound statement: expected statement">;
+def ext_c_label_end_of_compound_statement : ExtWarn<

This is not an error in C2x or in C++2b.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133887

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


[PATCH] D134176: Add MC support of RISCV Zcf Extension

2022-09-19 Thread Xinlong Wu via Phabricator via cfe-commits
VincentWu created this revision.
VincentWu added reviewers: kito-cheng, MaskRay, craig.topper, jrtc27, 
HsiangKai, asb.
Herald added subscribers: sunshaoce, StephenFan, vkmr, frasercrmck, evandro, 
luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, 
PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, 
shiva0217, niosHD, sabuasal, simoncook, johnrusso, rbar, hiraditya, arichardson.
Herald added a project: All.
VincentWu requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, pcwang-thead, eopXD.
Herald added projects: clang, LLVM.

This patch add the instructions of Zcf extension.

Zcf is a subset of C Ext which include the single-precision floating-point 
instructions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134176

Files:
  clang/test/Preprocessor/riscv-target-features.c
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoC.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/MC/RISCV/rv32fc-valid.s

Index: llvm/test/MC/RISCV/rv32fc-valid.s
===
--- llvm/test/MC/RISCV/rv32fc-valid.s
+++ llvm/test/MC/RISCV/rv32fc-valid.s
@@ -19,25 +19,25 @@
 # CHECK-ASM-AND-OBJ: c.flwsp  fs0, 252(sp)
 # CHECK-ASM: encoding: [0x7e,0x74]
 # CHECK-NO-EXT-F:  error: instruction requires the following: 'F' (Single-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions), 'F' (Single-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcf' (Compressed Single-Precision Floating-Point Instructions), 'F' (Single-Precision Floating-Point){{$}}
 # CHECK-NO-RV32:  error: instruction requires the following: RV32I Base Instruction Set{{$}}
 c.flwsp  fs0, 252(sp)
 # CHECK-ASM-AND-OBJ: c.fswsp  fa7, 252(sp)
 # CHECK-ASM: encoding: [0xc6,0xff]
 # CHECK-NO-EXT-F:  error: instruction requires the following: 'F' (Single-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions), 'F' (Single-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcf' (Compressed Single-Precision Floating-Point Instructions), 'F' (Single-Precision Floating-Point){{$}}
 # CHECK-NO-RV32:  error: instruction requires the following: RV32I Base Instruction Set{{$}}
 c.fswsp  fa7, 252(sp)
 
 # CHECK-ASM-AND-OBJ: c.flw  fa3, 124(a5)
 # CHECK-ASM: encoding: [0xf4,0x7f]
 # CHECK-NO-EXT-F:  error: instruction requires the following: 'F' (Single-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions), 'F' (Single-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcf' (Compressed Single-Precision Floating-Point Instructions), 'F' (Single-Precision Floating-Point){{$}}
 # CHECK-NO-RV32:  error: instruction requires the following: RV32I Base Instruction Set{{$}}
 c.flw  fa3, 124(a5)
 # CHECK-ASM-AND-OBJ: c.fsw  fa2, 124(a1)
 # CHECK-ASM: encoding: [0xf0,0xfd]
 # CHECK-NO-EXT-F:  error: instruction requires the following: 'F' (Single-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions), 'F' (Single-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcf' (Compressed Single-Precision Floating-Point Instructions), 'F' (Single-Precision Floating-Point){{$}}
 # CHECK-NO-RV32:  error: instruction requires the following: RV32I Base Instruction Set{{$}}
 c.fsw  fa2, 124(a1)
Index: llvm/lib/Target/RISCV/RISCVSubtarget.h
===
--- llvm/lib/Target/RISCV/RISCVSubtarget.h
+++ llvm/lib/Target/RISCV/RISCVSubtarget.h
@@ -62,6 +62,7 @@
   bool HasStdExtZbs = false;
   bool HasStdExtZbt = false;
   bool HasStdExtZca = false;
+  bool HasStdExtZcf = false;
   bool HasStdExtV = false;
   bool HasStdExtZve32x = false;
   bool HasStdExtZve32f = false;
@@ -172,6 +173,7 @@
   bool hasStdExtZbs() const { return HasStdExtZbs; }
   bool hasStdExtZbt() const { return HasStdExtZbt; }
   bool hasStdExtZca() const { return HasStdExtZca; }
+  bool hasStdExtZcf() const { return HasStdExtZcf; }
   bool hasStdExtZvl() const { return ZvlLen != 0; }
   bool hasStdExtZvfh() const { return HasStdExtZvfh; }
   bool hasStdExtZfhmin() const { return HasStdExtZfhmin; }
Index: llvm/lib/Target/RISCV/RISCVInstrInfoC.td
===
--- llvm/lib/Target/RISCV/RISCVInstrInfoC.td
+++ llvm/lib/Target/RISCV/RISCVInstrInfoC.td
@@ -328,7 +328,7 @@
 }
 
 let DecoderNamespace = "RISCV32Only_",
-Predicates = [HasStdExtC,

[PATCH] D134177: Add MC support of RISCV Zcd Extension

2022-09-19 Thread Xinlong Wu via Phabricator via cfe-commits
VincentWu created this revision.
VincentWu added reviewers: kito-cheng, MaskRay, craig.topper, jrtc27, 
HsiangKai, asb.
Herald added subscribers: sunshaoce, StephenFan, vkmr, frasercrmck, evandro, 
luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, 
PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, 
shiva0217, niosHD, sabuasal, simoncook, johnrusso, rbar, hiraditya, arichardson.
Herald added a project: All.
VincentWu requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, pcwang-thead, eopXD.
Herald added projects: clang, LLVM.

This patch add the instructions of Zcd extension.

Zcd is a subset of C Ext which include the double-precision floating-point 
instructions (c.fld, c.fldsp, c.fsd, c.fsdsp).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134177

Files:
  clang/test/Preprocessor/riscv-target-features.c
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoC.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/MC/RISCV/rv32dc-valid.s
  llvm/test/MC/RISCV/rv64dc-valid.s

Index: llvm/test/MC/RISCV/rv64dc-valid.s
===
--- llvm/test/MC/RISCV/rv64dc-valid.s
+++ llvm/test/MC/RISCV/rv64dc-valid.s
@@ -13,21 +13,21 @@
 # CHECK-ASM-AND-OBJ: c.fldsp  fs0, 504(sp)
 # CHECK-ASM: encoding: [0x7e,0x34]
 # CHECK-NO-EXT-D:  error: instruction requires the following: 'D' (Double-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-DC:  error: instruction requires the following: 'C' (Compressed Instructions), 'D' (Double-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-DC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcd' (Compressed Double-Precision Floating-Point Instructions), 'D' (Double-Precision Floating-Point){{$}}
 c.fldsp  fs0, 504(sp)
 # CHECK-ASM-AND-OBJ: c.fsdsp  fa7, 504(sp)
 # CHECK-ASM: encoding: [0xc6,0xbf]
 # CHECK-NO-EXT-D:  error: instruction requires the following: 'D' (Double-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-DC:  error: instruction requires the following: 'C' (Compressed Instructions), 'D' (Double-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-DC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcd' (Compressed Double-Precision Floating-Point Instructions), 'D' (Double-Precision Floating-Point){{$}}
 c.fsdsp  fa7, 504(sp)
 
 # CHECK-ASM-AND-OBJ: c.fld  fa3, 248(a5)
 # CHECK-ASM: encoding: [0xf4,0x3f]
 # CHECK-NO-EXT-D:  error: instruction requires the following: 'D' (Double-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-DC:  error: instruction requires the following: 'C' (Compressed Instructions), 'D' (Double-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-DC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcd' (Compressed Double-Precision Floating-Point Instructions), 'D' (Double-Precision Floating-Point){{$}}
 c.fld  fa3, 248(a5)
 # CHECK-ASM-AND-OBJ: c.fsd  fa2, 248(a1)
 # CHECK-ASM: encoding: [0xf0,0xbd]
 # CHECK-NO-EXT-D:  error: instruction requires the following: 'D' (Double-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-DC:  error: instruction requires the following: 'C' (Compressed Instructions), 'D' (Double-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-DC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcd' (Compressed Double-Precision Floating-Point Instructions), 'D' (Double-Precision Floating-Point){{$}}
 c.fsd  fa2, 248(a1)
Index: llvm/test/MC/RISCV/rv32dc-valid.s
===
--- llvm/test/MC/RISCV/rv32dc-valid.s
+++ llvm/test/MC/RISCV/rv32dc-valid.s
@@ -13,21 +13,21 @@
 # CHECK-ASM-AND-OBJ: c.fldsp  fs0, 504(sp)
 # CHECK-ASM: encoding: [0x7e,0x34]
 # CHECK-NO-EXT-D:  error: instruction requires the following: 'D' (Double-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-DC:  error: instruction requires the following: 'C' (Compressed Instructions), 'D' (Double-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-DC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcd' (Compressed Double-Precision Floating-Point Instructions), 'D' (Double-Precision Floating-Point){{$}}
 c.fldsp  fs0, 504(sp)
 # CHECK-ASM-AND-OBJ: c.fsdsp  fa7, 504(sp)
 # CHECK-ASM: encoding: [0xc6,0xbf]
 # CHECK-NO-EXT-D:  error: instruction requires the following: 'D' (Double-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-DC:  error: instruction requires the following: 'C' (Compressed Instructions), 'D' (Double-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-DC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcd' (Compressed Double-Precision Floating-Point Instructions), 'D' (Double-Precision Floating-Point){{$}}
 c.fsdsp  fa7, 504(sp)
 
 # CHECK-ASM-AND-OBJ: c.fld  fa3, 248(a5)
 # CHECK-ASM: encoding: [0xf4,0x3f]
 # CHECK-NO-EXT-D:  error: instruction requires the foll

[PATCH] D133853: [AST] Add msvc-specific C++11 attributes

2022-09-19 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D133853#3797598 , @RIscRIpt wrote:

> In D133853#3795579 , @aaron.ballman 
> wrote:
>
>> FWIW, one Microsoft-specific attribute I know people have been asking about 
>> is `[[msvc::no_unique_address]]`
>
> Thanks for letting me know.
>
> The current patch is my first attempt to contribute to LLVM; I am afraid it 
> would take me some effort to implement semantics of 
> `[[msvc::no_unique_address]]`, so I'd like to focus only on 
> `[[msvc::constexpr]]` in current patch.

No worries, thanks for at least thinking about it!

> In D133853#3795598 , @erichkeane 
> wrote:
>
>> A functional `msvc::constexpr` would be acceptable, however, I'm having a 
>> difficult time figuring out the purpose of it, it seems like it is just a 
>> 'constexpr keyword' replacement?

It's a conforming extension in older language modes like C++98, where we 
couldn't steal the `constexpr` keyword because it's not reserved, which is one 
benefit to it. Does MSVC support this as far back as C++98?

>> I believe the 'unknown attribute' warning for them is superior to an ignored 
>> attribute.
>
> By the way, I'd like to take opportunity and ask what do you think of adding 
> clang-specific compiler flag, which would add all unknown attributes to the 
> AST in a string form (e.g. `[[attr1]] -> AST::UnknownAttr{"attr1"}`? Would 
> you be interested in such patch?

We would be, but it's tricky. The idea we've had in mind for a while is to add 
an `UnknownAttr` type which wraps information the parser was able to scrape 
together. Things like the vendor namespace and attribute name are quite easy to 
keep around and would be a good initial offering. However, attribute arguments 
are going to be more difficult to handle because they can be arbitrary token 
soup rather than code which forms a valid AST node. e.g., `[[foo("oh no!")]]` 
isn't bad but `[[foo(we don't even know what this is)]]` and we can't even 
necessarily save off tokens for it because it could contain punctuation which 
isn't a valid token by itself, like `'` without a terminating single quote). So 
the initial offering could save the source range of the parens for the 
arguments (this way you can at least get back to the text in the source code if 
you need to), but I don't know that we have a good idea how to handle exposing 
the argument information.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133853

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


[PATCH] D133887: [Clang] Support label at end of compound statement

2022-09-19 Thread Evgeny Shulgin via Phabricator via cfe-commits
Izaron added a comment.

In D133887#3799310 , @aaron.ballman 
wrote:

> Thank you for working on this! I spotted an issue where we're not quite 
> complete with this implementation work. I pushed up a new test case in 
> https://github.com/llvm/llvm-project/commit/a244194f73788de6dfd6d753ff09be3625613f9f
>  that shows it (and set the C status page back to Partial in case this takes 
> a while to address), but `case` and `default` labels should be accepted the 
> same as any other label at the end of a compound statement.
>
> Btw, when working on C standards features, I've started adding test coverage 
> that demonstrates we fully implement the paper into the `clang/test/C/` 
> directory, under the correct standard version. This helps us to track the 
> status of proposals a bit more easily within the code base.

Hi! Thanks for this information! How did you find out that we should accept 
labels at end of statement in **C**, but not in **C++**? That is not obvious 
for me unfortunately. If C supports it, why would C++ not support it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133887

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


[PATCH] D133887: [Clang] Support label at end of compound statement

2022-09-19 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D133887#3799347 , @Izaron wrote:

> In D133887#3799310 , @aaron.ballman 
> wrote:
>
>> Thank you for working on this! I spotted an issue where we're not quite 
>> complete with this implementation work. I pushed up a new test case in 
>> https://github.com/llvm/llvm-project/commit/a244194f73788de6dfd6d753ff09be3625613f9f
>>  that shows it (and set the C status page back to Partial in case this takes 
>> a while to address), but `case` and `default` labels should be accepted the 
>> same as any other label at the end of a compound statement.
>>
>> Btw, when working on C standards features, I've started adding test coverage 
>> that demonstrates we fully implement the paper into the `clang/test/C/` 
>> directory, under the correct standard version. This helps us to track the 
>> status of proposals a bit more easily within the code base.
>
> Hi! Thanks for this information! How did you find out that we should accept 
> labels at end of statement in **C**, but not in **C++**? That is not obvious 
> for me unfortunately. If C supports it, why would C++ not support it?

I knew the answer for C off the top of my head, but was still looking up the 
info for C++. C++ does actually behave the same way:

https://eel.is/c++draft/stmt.label#1 -- `case` and `default` are both a `label`
https://eel.is/c++draft/stmt.block#1.sentence-2 -- all labels at the end of a 
compound statement are treated as if they are followed by a null statement
https://eel.is/c++draft/stmt.stmt#nt:selection-statement -- a `switch` is 
followed by a `statement`
https://eel.is/c++draft/stmt.stmt#stmt.pre-1 -- a `compound-statement` is a 
`statement`

I can fix up the C++ status page as well if you'd like, or I can hold off if 
you're already working on this, it's up to you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133887

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


[PATCH] D133934: [clang][Interp] Handle sizeof() expressions

2022-09-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane accepted this revision.
erichkeane added a comment.
This revision is now accepted and ready to land.

I think we're OK for now, LGTM.


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

https://reviews.llvm.org/D133934

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


[PATCH] D134180: [clang] Fix a nullptr-access crash in CheckTemplateArgument.

2022-09-19 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added reviewers: kadircet, adamcz.
Herald added a project: All.
hokein requested review of this revision.
Herald added a project: clang.

It is possible that we can pass a null ParamType to
CheckNonTypeTemplateParameter -- the ParamType var can be reset to a null
type on Line 6940, and the followed bailout if is not entered.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134180

Files:
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp


Index: clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
@@ -558,3 +558,24 @@
   X<1, 1u>::type y; // expected-error {{no type named 'type' in 
'TypeSuffix::X<1, 1U>'}}
   X<1, 1>::type z; // expected-error {{no type named 'type' in 
'TypeSuffix::X<1, 1>'}}
 }
+
+namespace no_crash {
+template 
+class Base {
+public:
+  template  class EntryPointSpec {};
+  template 
+  using EntryPoint = EntryPointSpec;
+};
+
+class Derived : Base{
+  template  class Spec {};
+
+  void Invalid(Undefined) const; // expected-error {{unknown type name 
'Undefined'}}
+  void crash() {
+return Spec{
+EntryPoint<&Invalid>()
+};
+  }
+};
+} // no_crash
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -6934,8 +6934,6 @@
   Expr *Inits[1] = {DeductionArg};
   ParamType =
   DeduceTemplateSpecializationFromInitializer(TSI, Entity, Kind, 
Inits);
-  if (ParamType.isNull())
-return ExprError();
 } else {
   TemplateDeductionInfo Info(DeductionArg->getExprLoc(),
  Param->getDepth() + 1);
@@ -6958,6 +6956,8 @@
 return ExprError();
   }
 }
+if (ParamType.isNull())
+  return ExprError();
 // CheckNonTypeTemplateParameterType will produce a diagnostic if there's
 // an error. The error message normally references the parameter
 // declaration, but here we'll pass the argument location because that's


Index: clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
@@ -558,3 +558,24 @@
   X<1, 1u>::type y; // expected-error {{no type named 'type' in 'TypeSuffix::X<1, 1U>'}}
   X<1, 1>::type z; // expected-error {{no type named 'type' in 'TypeSuffix::X<1, 1>'}}
 }
+
+namespace no_crash {
+template 
+class Base {
+public:
+  template  class EntryPointSpec {};
+  template 
+  using EntryPoint = EntryPointSpec;
+};
+
+class Derived : Base{
+  template  class Spec {};
+
+  void Invalid(Undefined) const; // expected-error {{unknown type name 'Undefined'}}
+  void crash() {
+return Spec{
+EntryPoint<&Invalid>()
+};
+  }
+};
+} // no_crash
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -6934,8 +6934,6 @@
   Expr *Inits[1] = {DeductionArg};
   ParamType =
   DeduceTemplateSpecializationFromInitializer(TSI, Entity, Kind, Inits);
-  if (ParamType.isNull())
-return ExprError();
 } else {
   TemplateDeductionInfo Info(DeductionArg->getExprLoc(),
  Param->getDepth() + 1);
@@ -6958,6 +6956,8 @@
 return ExprError();
   }
 }
+if (ParamType.isNull())
+  return ExprError();
 // CheckNonTypeTemplateParameterType will produce a diagnostic if there's
 // an error. The error message normally references the parameter
 // declaration, but here we'll pass the argument location because that's
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D133887: [Clang] Support label at end of compound statement

2022-09-19 Thread Evgeny Shulgin via Phabricator via cfe-commits
Izaron added a comment.

In D133887#3799399 , @aaron.ballman 
wrote:

> I can fix up the C++ status page as well if you'd like, or I can hold off if 
> you're already working on this, it's up to you!

Thank you! I'll support empty labels in switch statements in a new pull request 
as soon as I can 😁


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133887

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


[PATCH] D134180: [clang] Fix a nullptr-access crash in CheckTemplateArgument.

2022-09-19 Thread Adam Czachorowski via Phabricator via cfe-commits
adamcz accepted this revision.
adamcz added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Sema/SemaTemplate.cpp:6960
+if (ParamType.isNull())
+  return ExprError();
 // CheckNonTypeTemplateParameterType will produce a diagnostic if there's

So this can only happen when Result is TDK_AlreadyDiagnosed above, right? In 
that case, I would handle such case explicitly in the code above, like:
if (Result == TDK_AlreadyDiagnosed) return ExprError();
else if (Result != TDK_Success) { ... }
Seems like it would be more readable. 

However, I am definitely not opposed to keeping this check here as well, in 
case there are other ways to get into this situation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134180

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


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

2022-09-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

I'm still having trouble from the description and test figuring out what this 
means.  Can you better clarify the intent/effect of this?

Is the point that the type-aliases could also store a non-canonicalized type?  
if so, perhaps the patch should better reflect that (AND, perhaps do some 
assertions to make sure we don't unintentionally store types that don't 
canonicalize identically).




Comment at: clang/include/clang/AST/Type.h:1802
+/// True if the underlying diverges from the declared one.
+unsigned isDivergent : 1;
+  };

It isn't clear to me what you mean by 'diverges' and 'divergent here.



Comment at: clang/lib/AST/Type.cpp:3443
+  if (isDivergent())
+*reinterpret_cast(this + 1) = Underlying;
 }

this bit doesn't seem right to me.  Why isn't this using the normal setter 
here?  Or even the trailing objects setter?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133468

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


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

2022-09-19 Thread Jamie Schmeiser via Phabricator via cfe-commits
jamieschmeiser added a comment.

Great.  Also, something you may want to consider, either as part of or after 
you land this code.  This really is a specific instance of a more generic 
problem: setting up option handling for something that saves results in a file 
for each compilation.  This is equally useful for other things such as listings 
and could also be used by something like print-changed (which currently just 
outputs to the stream), opt stats reporting, etc.  This code could be organized 
as a function (or possibly an object, depends...) that takes  a string for the 
extension, a lambda/template for the virtual call on whether to add the option 
to a tool so that off-handling, platform-isms, and where files are saved would 
all be captured neatly and would be re-usable.  InferTimeTrace and getPath, 
off-loading, platform-isms would be captured in a generic call that would look 
something like (in this instance)

  PerFileTraceGenerator(".json",
   [](Tool &T, Args &Args)->bool{ return T->supportsTimeTrace() && 
Args.hasArg(options::OPT_ftime_trace, options::OPT_ftime_trace_EQ; },
   "-ftime-trace="); 

Each option that needs per file output would just call this function 
appropriately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133662

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


[PATCH] D133887: [Clang] Support label at end of compound statement

2022-09-19 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D133887#3799450 , @Izaron wrote:

> In D133887#3799399 , @aaron.ballman 
> wrote:
>
>> I can fix up the C++ status page as well if you'd like, or I can hold off if 
>> you're already working on this, it's up to you!
>
> Thank you! I'll support empty labels in switch statements in a new pull 
> request as soon as I can 😁

Thank you, I appreciate it!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133887

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


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

2022-09-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Patch generally seems OK to me. I would vastly prefer a better commit message 
explaining the intent here.  Also, not quite sure I see the need for the extra 
bit?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132816

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


[PATCH] D134128: Resubmit an implemention for constrained template template parameters [P0857R0 Part B]

2022-09-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Thanks for taking this over!  FIRST, please make sure you re-submit this with 
the entire 'context' (see context-not-available), by making sure you use 
-U99 on your patch before uploading it.

It DOES appear from the tests that we're already checking everything we're 
supposed to?

ALSO, could you please try rebasing this on top of 
"https://reviews.llvm.org/D126907"; to see if it causes any further issues for 
that?  I'm nearing a solution to my last problem on that, and would love to get 
that submitted in the next week or two, and knowing if this/these tests are 
going to break it would be an appreciated heads-up.




Comment at: clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp:39
+S4 s41;
+S4 s42; // expected-error{{template template argument 'Y' is more 
constrained than template template parameter 'P'}}
+S4 s43;

I realize the rest of the test does a poor job of this, but can you better 
arrange the new diagnostics for me, rather thanputting the 'note's on teh 
individual lines?  

I prefer to have them in 'emitted order' next to the error/warning that caused 
the notes. You can do an "@" on 'expected-note' that refers to a different line 
by putting a `// #SOME_BOOKMARK_NAME` on the line that has the note, and 
`expected-note@#SOME_BOOKMARK_NAME` here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134128

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


[PATCH] D110641: Implement P0857R0 -Part B: requires clause for template-template params

2022-09-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane abandoned this revision.
erichkeane added a comment.

Taken over by someone else here: https://reviews.llvm.org/D134128


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

https://reviews.llvm.org/D110641

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


[PATCH] D134145: [Clang] Implement fix for DR2628

2022-09-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane accepted this revision.
erichkeane added a comment.
This revision is now accepted and ready to land.

This seems right to me, thanks!

I'm currently pushing to try to make our diagnostics 'check' lines more 
readable... it doesn't gain a ton in this case, but more to try to push for 
consistency.




Comment at: clang/test/CXX/drs/dr26xx.cpp:7
+struct foo {
+  constexpr foo() requires (!A && !B) = delete; // expected-note {{marked 
deleted here}}
+  constexpr foo() requires (A || B) = delete;





Comment at: clang/test/CXX/drs/dr26xx.cpp:12
+void f() {
+  foo fooable; // expected-error {{call to deleted}}
+}




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134145

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


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

2022-09-19 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added a comment.

In D133468#3799475 , @erichkeane 
wrote:

> I'm still having trouble from the description and test figuring out what this 
> means.  Can you better clarify the intent/effect of this?

The effect is that you can effectively have a TypedefType/UsingType that has an 
underlying type that is not identical to the one which is held in the 
TypedefDecl/UsingDecl.

Another way we could achieve this, though I am saying it just for exposition as 
it wouldn't be good, would be by emitting a redeclaration with the type we 
want. The reason that is not good is because redeclarations are expensive to 
create and they are not uniqued, and they would waste a lot of memory.

Want we really want this for is resugaring: A TypedefType can have a dependent 
type, and then when an instantiation of that is created, it will have a Type 
substitution node that only references the canonical type of the template 
argument used to instantiate it.
With resugaring, we can replace that underlying type with one referencing the 
original argument, and would thus necessitate to "change" the underlying type. 
We don't want to emit redeclarations during resugaring as that is too 
expensive, as I explained.

Since resugaring is not implemented before this patch, and in order to test 
this functionality, we use a nifty trick that became possible after we merged 
D130308 : We can unify two different 
TypedefTypes/UsingTypes that refer to different TypedefDecl/UsingDecl 
redeclarations (as written in source), each redeclaration having a 
non-identical type, which after unification becomes yet a different type, which 
we will use as the underlying type of our unified TypedefType/UsingType.

> Is the point that the type-aliases could also store a non-canonicalized type? 
>  if so, perhaps the patch should better reflect that (AND, perhaps do some 
> assertions to make sure we don't unintentionally store types that don't 
> canonicalize identically).

They can store a separate QualType which must be the SameType as their 
canonical type, yes.

The assertion is already in place for both TypedefType and UsingType 
constructors.




Comment at: clang/include/clang/AST/Type.h:1802
+/// True if the underlying diverges from the declared one.
+unsigned isDivergent : 1;
+  };

erichkeane wrote:
> It isn't clear to me what you mean by 'diverges' and 'divergent here.
I ate the `type`, will fix that, but what I mean here is that a 
TypedefType/UsingType, without this patch, can only have the same type as is 
declared in the declaration it references.

With this patch, if the UnderlyingType passed in the constructor is different 
from the one that is declared, then the node will be able to hold this 
different type, and we will say that the node is 'divergent', which is the term 
I came up with, synonymous with different.



Comment at: clang/lib/AST/Type.cpp:3443
+  if (isDivergent())
+*reinterpret_cast(this + 1) = Underlying;
 }

erichkeane wrote:
> this bit doesn't seem right to me.  Why isn't this using the normal setter 
> here?  Or even the trailing objects setter?
Well there isn't supposed to be a normal setter, but right, I forgot to update 
this to use the trailing objects setter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133468

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


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

2022-09-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Thanks for the explanation, I think that makes more sense to me.  A summarized 
version in the commit message would be appreciated.

As far as the 'asserts', i see them now in the `ASTContext` functions.

as far as `Divergent`, I wonder if we should call it something more 
descriptive, since it isn't just that it 'differs', it is that it is a 
non-canonical version, right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133468

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


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

2022-09-19 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added a comment.

In D132816#3799484 , @erichkeane 
wrote:

> Patch generally seems OK to me. I would vastly prefer a better commit message 
> explaining the intent here.  Also, not quite sure I see the need for the 
> extra bit?

Well mechanically the low level intent is explained in the commit summary, and 
it does give some benefits without any further patches as now we can represent 
better in the AST some substitutions related to default arguments in template 
template parameters, and some other substitutions performed in concepts 
checking.

But the important reason is that with resugaring, this will allow us to produce 
a resugared type which still contains SubstNodes marking the original 
substitutions, otherwise we would have to wipe that out and we wouldn't be able 
to resugar these types again if needed.

The extra bit is for saving storage when the underlying type is already 
canonical, so that this patch has minimal memory usage impact.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132816

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


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

2022-09-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D132816#3799535 , @mizvekov wrote:

> In D132816#3799484 , @erichkeane 
> wrote:
>
>> Patch generally seems OK to me. I would vastly prefer a better commit 
>> message explaining the intent here.  Also, not quite sure I see the need for 
>> the extra bit?
>
> Well mechanically the low level intent is explained in the commit summary, 
> and it does give some benefits without any further patches as now we can 
> represent better in the AST some substitutions related to default arguments 
> in template template parameters, and some other substitutions performed in 
> concepts checking.
>
> But the important reason is that with resugaring, this will allow us to 
> produce a resugared type which still contains SubstNodes marking the original 
> substitutions, otherwise we would have to wipe that out and we wouldn't be 
> able to resugar these types again if needed.
>
> The extra bit is for saving storage when the underlying type is already 
> canonical, so that this patch has minimal memory usage impact.

Woops, sorry about the 'extra bit' part, that was because of a comment I had 
and deleted, I was suggesting at one point that the bit should be a property of 
the 'underlying type' (that is, determine it based on the canonicalness of the 
underlying type), but I think I figured out why it wouldn't be necessary.

As far as the "commit summary", the patch summary at least is empty...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132816

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


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

2022-09-19 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added a comment.

In D133468#3799522 , @erichkeane 
wrote:

> as far as `Divergent`, I wonder if we should call it something more 
> descriptive, since it isn't just that it 'differs', it is that it is a 
> non-canonical version, right?

Well, currently without this patch TypedefTypes and UsingTypes can already have 
a non-canonical underlying type, it's just that we only store a reference to 
the declaration and we access the non-canonical type from there.

The canonical type is still stored in the type itself, like any other type of 
course.

"Divergent" is a term I came up with, but I would be all ears for a better 
alternative.

I considered that calling it just `Different` but that didn't sound right, even 
though its synonymous.

I considered calling it `hasDifferentUnderlyingTypefromDeclaration` but felt 
that was too verbose.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133468

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


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

2022-09-19 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added a comment.

In D132816#3799543 , @erichkeane 
wrote:

> As far as the "commit summary", the patch summary at least is empty...

Yeah I meant the one line title of the commit, but I will update it to include 
a summary with further elaboration in a bit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132816

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


[PATCH] D133982: [clangd] Improve inlay hints of things expanded from macros

2022-09-19 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/InlayHints.cpp:281
 
-  void addReturnTypeHint(FunctionDecl *D, SourceLocation Loc) {
+  void addReturnTypeHint(FunctionDecl *D, SourceRange Range) {
 auto *AT = D->getReturnType()->getContainedAutoType();

nridge wrote:
> Is this change related to the fix?
Only tangentially...

This change makes the whole range significant (previously it was serialized but 
I think not used by any clients these days). So hiding the token->range 
conversion inside this function might encourage bugs in the future, even if 
today all the callers do that.

(I did consider attaching the return type hints to e.g. the parens range rather 
than a single paren, but can't think of a motivating case in either direction 
really)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133982

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


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

2022-09-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D133468#3799557 , @mizvekov wrote:

> In D133468#3799522 , @erichkeane 
> wrote:
>
>> as far as `Divergent`, I wonder if we should call it something more 
>> descriptive, since it isn't just that it 'differs', it is that it is a 
>> non-canonical version, right?
>
> Well, currently without this patch TypedefTypes and UsingTypes can already 
> have a non-canonical underlying type, it's just that we only store a 
> reference to the declaration and we access the non-canonical type from there.

Ah, right, hrmph.

> The canonical type is still stored in the type itself, like any other type of 
> course.
>
> "Divergent" is a term I came up with, but I would be all ears for a better 
> alternative.
>
> I considered that calling it just `Different` but that didn't sound right, 
> even though its synonymous.
>
> I considered calling it `hasDifferentUnderlyingTypefromDeclaration` but felt 
> that was too verbose.

I agree with all of that, but still am not thrilled at 'Divergent', it isn't 
particularly descriptive... `Divergent` has some additional implications that 
I'm not sure we mean as well (that is, it isn't a perfect synonym for 
`different`).

Perhaps something more like `hasLessCanonicalizedType` or `hasMoreSpecificType` 
or something like that?  I'm grasping a little, but I think I would like it to 
be more clear that we're storing the SAME type, just with additional sugar.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133468

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


[clang-tools-extra] 924974a - [clangd] Improve inlay hints of things expanded from macros

2022-09-19 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2022-09-19T16:44:21+02:00
New Revision: 924974a3a13b03090d04860f209ce11b3d9d00a6

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

LOG: [clangd] Improve inlay hints of things expanded from macros

When we aim a hint at some expanded tokens, we're only willing to attach it
to spelled tokens that exactly corresponde.

e.g.
int zoom(int x, int y, int z);
int dummy = zoom(NUMBERS);

Here we want to place a hint "x:" on the expanded "1", but we shouldn't
be willing to place it on NUMBERS, because it doesn't *exactly*
correspond (it has more tokens).

Fortunately we don't even have to implement this algorithm from scratch,
TokenBuffer has it.

Fixes https://github.com/clangd/clangd/issues/1289
Fixes https://github.com/clangd/clangd/issues/1118
Fixes https://github.com/clangd/clangd/issues/1018

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

Added: 


Modified: 
clang-tools-extra/clangd/InlayHints.cpp
clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/InlayHints.cpp 
b/clang-tools-extra/clangd/InlayHints.cpp
index bff07dd078cc9..16c6b1cecc031 100644
--- a/clang-tools-extra/clangd/InlayHints.cpp
+++ b/clang-tools-extra/clangd/InlayHints.cpp
@@ -10,6 +10,7 @@
 #include "Config.h"
 #include "HeuristicResolver.h"
 #include "ParsedAST.h"
+#include "SourceCode.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclarationName.h"
 #include "clang/AST/ExprCXX.h"
@@ -192,8 +193,8 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
 public:
   InlayHintVisitor(std::vector &Results, ParsedAST &AST,
const Config &Cfg, llvm::Optional RestrictRange)
-  : Results(Results), AST(AST.getASTContext()), Cfg(Cfg),
-RestrictRange(std::move(RestrictRange)),
+  : Results(Results), AST(AST.getASTContext()), Tokens(AST.getTokens()),
+Cfg(Cfg), RestrictRange(std::move(RestrictRange)),
 MainFileID(AST.getSourceManager().getMainFileID()),
 Resolver(AST.getHeuristicResolver()),
 TypeHintPolicy(this->AST.getPrintingPolicy()),
@@ -227,8 +228,7 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
   return true;
 }
 
-processCall(E->getParenOrBraceRange().getBegin(), E->getConstructor(),
-{E->getArgs(), E->getNumArgs()});
+processCall(E->getConstructor(), {E->getArgs(), E->getNumArgs()});
 return true;
   }
 
@@ -254,7 +254,7 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
 if (!Callee)
   return true;
 
-processCall(E->getRParenLoc(), Callee, {E->getArgs(), E->getNumArgs()});
+processCall(Callee, {E->getArgs(), E->getNumArgs()});
 return true;
   }
 
@@ -278,11 +278,11 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
 return true;
   }
 
-  void addReturnTypeHint(FunctionDecl *D, SourceLocation Loc) {
+  void addReturnTypeHint(FunctionDecl *D, SourceRange Range) {
 auto *AT = D->getReturnType()->getContainedAutoType();
 if (!AT || AT->getDeducedType().isNull())
   return;
-addTypeHint(Loc, D->getReturnType(), /*Prefix=*/"-> ");
+addTypeHint(Range, D->getReturnType(), /*Prefix=*/"-> ");
   }
 
   bool VisitVarDecl(VarDecl *D) {
@@ -375,21 +375,11 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
 private:
   using NameVec = SmallVector;
 
-  // The purpose of Anchor is to deal with macros. It should be the call's
-  // opening or closing parenthesis or brace. (Always using the opening would
-  // make more sense but CallExpr only exposes the closing.) We heuristically
-  // assume that if this location does not come from a macro definition, then
-  // the entire argument list likely appears in the main file and can be 
hinted.
-  void processCall(SourceLocation Anchor, const FunctionDecl *Callee,
+  void processCall(const FunctionDecl *Callee,
llvm::ArrayRef Args) {
 if (!Cfg.InlayHints.Parameters || Args.size() == 0 || !Callee)
   return;
 
-// If the anchor location comes from a macro definition, there's nowhere to
-// put hints.
-if (!AST.getSourceManager().getTopMacroCallerLoc(Anchor).isFileID())
-  return;
-
 // The parameter name of a move or copy constructor is not very 
interesting.
 if (auto *Ctor = dyn_cast(Callee))
   if (Ctor->isCopyOrMoveConstructor())
@@ -637,25 +627,33 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
 #undef CHECK_KIND
 }
 
-auto FileRange =
-toHalfOpenFileRange(AST.getSourceManager(), AST.getLangOpts(), R);
-if (!FileRange)
+auto LSPRange = getHintRange(R);
+if (!LSPRange)
   return;
-Range LSPRange{
-sourceLocToPosition(AST.getSourceManager(), FileRange->getBegin()),
-sourceLocToPosition(AS

[PATCH] D133982: [clangd] Improve inlay hints of things expanded from macros

2022-09-19 Thread Sam McCall via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG924974a3a13b: [clangd] Improve inlay hints of things 
expanded from macros (authored by sammccall).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133982

Files:
  clang-tools-extra/clangd/InlayHints.cpp
  clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Index: clang-tools-extra/clangd/unittests/InlayHintTests.cpp
===
--- clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -820,6 +820,15 @@
 }
   )cpp",
ExpectedHint{"param: ", "param"});
+
+  // If the macro expands to multiple arguments, don't hint it.
+  assertParameterHints(R"cpp(
+void foo(double x, double y);
+#define CONSTANTS 3.14, 2.72
+void bar() {
+  foo(CONSTANTS);
+}
+  )cpp");
 }
 
 TEST(ParameterHints, ConstructorParens) {
Index: clang-tools-extra/clangd/InlayHints.cpp
===
--- clang-tools-extra/clangd/InlayHints.cpp
+++ clang-tools-extra/clangd/InlayHints.cpp
@@ -10,6 +10,7 @@
 #include "Config.h"
 #include "HeuristicResolver.h"
 #include "ParsedAST.h"
+#include "SourceCode.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclarationName.h"
 #include "clang/AST/ExprCXX.h"
@@ -192,8 +193,8 @@
 public:
   InlayHintVisitor(std::vector &Results, ParsedAST &AST,
const Config &Cfg, llvm::Optional RestrictRange)
-  : Results(Results), AST(AST.getASTContext()), Cfg(Cfg),
-RestrictRange(std::move(RestrictRange)),
+  : Results(Results), AST(AST.getASTContext()), Tokens(AST.getTokens()),
+Cfg(Cfg), RestrictRange(std::move(RestrictRange)),
 MainFileID(AST.getSourceManager().getMainFileID()),
 Resolver(AST.getHeuristicResolver()),
 TypeHintPolicy(this->AST.getPrintingPolicy()),
@@ -227,8 +228,7 @@
   return true;
 }
 
-processCall(E->getParenOrBraceRange().getBegin(), E->getConstructor(),
-{E->getArgs(), E->getNumArgs()});
+processCall(E->getConstructor(), {E->getArgs(), E->getNumArgs()});
 return true;
   }
 
@@ -254,7 +254,7 @@
 if (!Callee)
   return true;
 
-processCall(E->getRParenLoc(), Callee, {E->getArgs(), E->getNumArgs()});
+processCall(Callee, {E->getArgs(), E->getNumArgs()});
 return true;
   }
 
@@ -278,11 +278,11 @@
 return true;
   }
 
-  void addReturnTypeHint(FunctionDecl *D, SourceLocation Loc) {
+  void addReturnTypeHint(FunctionDecl *D, SourceRange Range) {
 auto *AT = D->getReturnType()->getContainedAutoType();
 if (!AT || AT->getDeducedType().isNull())
   return;
-addTypeHint(Loc, D->getReturnType(), /*Prefix=*/"-> ");
+addTypeHint(Range, D->getReturnType(), /*Prefix=*/"-> ");
   }
 
   bool VisitVarDecl(VarDecl *D) {
@@ -375,21 +375,11 @@
 private:
   using NameVec = SmallVector;
 
-  // The purpose of Anchor is to deal with macros. It should be the call's
-  // opening or closing parenthesis or brace. (Always using the opening would
-  // make more sense but CallExpr only exposes the closing.) We heuristically
-  // assume that if this location does not come from a macro definition, then
-  // the entire argument list likely appears in the main file and can be hinted.
-  void processCall(SourceLocation Anchor, const FunctionDecl *Callee,
+  void processCall(const FunctionDecl *Callee,
llvm::ArrayRef Args) {
 if (!Cfg.InlayHints.Parameters || Args.size() == 0 || !Callee)
   return;
 
-// If the anchor location comes from a macro definition, there's nowhere to
-// put hints.
-if (!AST.getSourceManager().getTopMacroCallerLoc(Anchor).isFileID())
-  return;
-
 // The parameter name of a move or copy constructor is not very interesting.
 if (auto *Ctor = dyn_cast(Callee))
   if (Ctor->isCopyOrMoveConstructor())
@@ -637,25 +627,33 @@
 #undef CHECK_KIND
 }
 
-auto FileRange =
-toHalfOpenFileRange(AST.getSourceManager(), AST.getLangOpts(), R);
-if (!FileRange)
+auto LSPRange = getHintRange(R);
+if (!LSPRange)
   return;
-Range LSPRange{
-sourceLocToPosition(AST.getSourceManager(), FileRange->getBegin()),
-sourceLocToPosition(AST.getSourceManager(), FileRange->getEnd())};
-Position LSPPos = Side == HintSide::Left ? LSPRange.start : LSPRange.end;
+Position LSPPos = Side == HintSide::Left ? LSPRange->start : LSPRange->end;
 if (RestrictRange &&
 (LSPPos < RestrictRange->start || !(LSPPos < RestrictRange->end)))
   return;
-// The hint may be in a file other than the main file (for example, a header
-// file that was included after the preamble), do not show in that case.
-if (!AST.getSourceManager().isWrittenInMainFile(FileRange->getBegi

[PATCH] D134175: [clang][Interp] Implement record instance functions and returning struct types

2022-09-19 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder updated this revision to Diff 461205.

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

https://reviews.llvm.org/D134175

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/ByteCodeStmtGen.cpp
  clang/test/AST/Interp/records.cpp

Index: clang/test/AST/Interp/records.cpp
===
--- clang/test/AST/Interp/records.cpp
+++ clang/test/AST/Interp/records.cpp
@@ -13,7 +13,8 @@
   int a = 20;
   int b = 30;
   bool c = true;
-  // BoolPair bp = {true, false}; FIXME
+  BoolPair bp = {true, false};
+  int numbers[3] = {1,2,3};
 
   static const int five = 5;
   static constexpr int getFive() {
@@ -37,6 +38,13 @@
 static_assert(ints.c, "");
 static_assert(ints.getTen() == 10, "");
 
+constexpr const BoolPair &BP = ints.bp;
+static_assert(BP.first, "");
+static_assert(!BP.second, "");
+static_assert(ints.bp.first, "");
+static_assert(!ints.bp.second, "");
+
+
 constexpr Ints ints2{-20, -30, false};
 static_assert(ints2.a == -20, "");
 static_assert(ints2.b == -30, "");
Index: clang/lib/AST/Interp/ByteCodeStmtGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeStmtGen.cpp
+++ clang/lib/AST/Interp/ByteCodeStmtGen.cpp
@@ -102,10 +102,9 @@
 for (const auto *Init : Ctor->inits()) {
   const FieldDecl *Member = Init->getMember();
   const Expr *InitExpr = Init->getInit();
+  const Record::Field *F = R->getField(Member);
 
   if (Optional T = this->classify(InitExpr->getType())) {
-const Record::Field *F = R->getField(Member);
-
 if (!this->emitDupPtr(InitExpr))
   return false;
 
@@ -115,7 +114,19 @@
 if (!this->emitInitField(*T, F->Offset, InitExpr))
   return false;
   } else {
-assert(false && "Handle initializer for non-primitive values");
+// Non-primitive case. Get a pointer to the field-to-initialize
+// on the stack and call visitInitialzer() for it.
+if (!this->emitDupPtr(InitExpr))
+  return false;
+
+if (!this->emitGetPtrField(F->Offset, InitExpr))
+  return false;
+
+if (!this->visitInitializer(InitExpr))
+  return false;
+
+if (!this->emitPopPtr(InitExpr))
+  return false;
   }
 }
   }
Index: clang/lib/AST/Interp/ByteCodeExprGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeExprGen.cpp
+++ clang/lib/AST/Interp/ByteCodeExprGen.cpp
@@ -611,9 +611,11 @@
   return false;
   } else if (Optional T = classify(InitType)) {
 // Visit the primitive element like normal.
+if (!this->emitDupPtr(Init))
+  return false;
 if (!this->visit(Init))
   return false;
-if (!this->emitInitElem(*T, ElementIndex, Init))
+if (!this->emitInitElemPop(*T, ElementIndex, Init))
   return false;
   } else {
 assert(false && "Unhandled type in array initializer initlist");
@@ -621,12 +623,13 @@
 
   ++ElementIndex;
 }
-
-  } else {
-assert(false && "Unknown expression for array initialization");
+return true;
+  } else if (const auto *DIE = dyn_cast(Initializer)) {
+return this->visitInitializer(DIE->getExpr());
   }
 
-  return true;
+  assert(false && "Unknown expression for array initialization");
+  return false;
 }
 
 template 
@@ -678,7 +681,10 @@
 
   return this->visit(CE);
 }
+  } else if (const auto *DIE = dyn_cast(Initializer)) {
+return this->visitInitializer(DIE->getExpr());
   }
+
   return false;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2022-09-19 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added a comment.

In D133468#3799572 , @erichkeane 
wrote:

> I agree with all of that, but still am not thrilled at 'Divergent', it isn't 
> particularly descriptive... `Divergent` has some additional implications that 
> I'm not sure we mean as well (that is, it isn't a perfect synonym for 
> `different`).

Yeah, it gives the sense of growing further apart, though that distinction 
would be meaningless for type nodes as they are not supposed to be mutable.

Divergent is a term that is already used within `llvm` subproject, but not in 
Clang.

> Perhaps something more like `hasLessCanonicalizedType` or 
> `hasMoreSpecificType` or something like that?  I'm grasping a little, but I 
> think I would like it to be more clear that we're storing the SAME type, just 
> with additional sugar.

Something like `hasDifferentSugaredType`, though that is still a bit on the 
long side.

I also considered `resugared`, that would be my preferred alternative I think, 
as it's short and specific.

One important consideration is that we will print this in the AST node dumper, 
so having a short name helps and we won't be compelled to use two different 
terms.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133468

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


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

2022-09-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane accepted this revision.
erichkeane added a comment.
This revision is now accepted and ready to land.

In D133468#3799609 , @mizvekov wrote:

> In D133468#3799572 , @erichkeane 
> wrote:
>
>> I agree with all of that, but still am not thrilled at 'Divergent', it isn't 
>> particularly descriptive... `Divergent` has some additional implications 
>> that I'm not sure we mean as well (that is, it isn't a perfect synonym for 
>> `different`).
>
> Yeah, it gives the sense of growing further apart, though that distinction 
> would be meaningless for type nodes as they are not supposed to be mutable.
>
> Divergent is a term that is already used within `llvm` subproject, but not in 
> Clang.
>
>> Perhaps something more like `hasLessCanonicalizedType` or 
>> `hasMoreSpecificType` or something like that?  I'm grasping a little, but I 
>> think I would like it to be more clear that we're storing the SAME type, 
>> just with additional sugar.
>
> Something like `hasDifferentSugaredType`, though that is still a bit on the 
> long side.
>
> I also considered `resugared`, that would be my preferred alternative I 
> think, as it's short and specific.
>
> One important consideration is that we will print this in the AST node 
> dumper, so having a short name helps and we won't be compelled to use two 
> different terms.

`hasDifferentSugaredType` is the best option I've seen so far.  I'm not in love 
with it, but it is definitely 'better'.  I don't think it is horrifyingly long, 
and we have similar length things throughout the codebase.  If you come up with 
something better, feel free to commit with it, else this patch LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133468

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


[clang-tools-extra] e424418 - [clangd] Allow programmatically disabling rename of virtual method hierarchies.

2022-09-19 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2022-09-19T16:59:28+02:00
New Revision: e4244183582721b1ff47be669f1a115625c46a2f

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

LOG: [clangd] Allow programmatically disabling rename of virtual method 
hierarchies.

This feature relies on Relations in the index being complete.
An out-of-tree index implementation is missing some override relations, so
such renames end up breaking the code.
We plan to fix it, but this flag is a cheap band-aid for now.

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

Added: 


Modified: 
clang-tools-extra/clangd/refactor/Rename.cpp
clang-tools-extra/clangd/refactor/Rename.h

Removed: 




diff  --git a/clang-tools-extra/clangd/refactor/Rename.cpp 
b/clang-tools-extra/clangd/refactor/Rename.cpp
index 6358a05667bd..4e367898c6bf 100644
--- a/clang-tools-extra/clangd/refactor/Rename.cpp
+++ b/clang-tools-extra/clangd/refactor/Rename.cpp
@@ -181,8 +181,15 @@ enum class ReasonToReject {
 
 llvm::Optional renameable(const NamedDecl &RenameDecl,
   StringRef MainFilePath,
-  const SymbolIndex *Index) {
+  const SymbolIndex *Index,
+  const RenameOptions& Opts) {
   trace::Span Tracer("Renameable");
+  if (!Opts.RenameVirtual) {
+if (const auto *S = llvm::dyn_cast(&RenameDecl)) {
+  if (S->isVirtual())
+return ReasonToReject::UnsupportedSymbol;
+}
+  }
   // Filter out symbols that are unsupported in both rename modes.
   if (llvm::isa(&RenameDecl))
 return ReasonToReject::UnsupportedSymbol;
@@ -746,7 +753,8 @@ llvm::Expected rename(const RenameInputs 
&RInputs) {
   if (Invalid)
 return makeError(std::move(*Invalid));
 
-  auto Reject = renameable(RenameDecl, RInputs.MainFilePath, RInputs.Index);
+  auto Reject =
+  renameable(RenameDecl, RInputs.MainFilePath, RInputs.Index, Opts);
   if (Reject)
 return makeError(*Reject);
 

diff  --git a/clang-tools-extra/clangd/refactor/Rename.h 
b/clang-tools-extra/clangd/refactor/Rename.h
index b4cdd1147fb6..036594e8bebd 100644
--- a/clang-tools-extra/clangd/refactor/Rename.h
+++ b/clang-tools-extra/clangd/refactor/Rename.h
@@ -26,6 +26,10 @@ struct RenameOptions {
   size_t LimitFiles = 50;
   /// If true, format the rename edits, only meaningful in ClangdServer layer.
   bool WantFormat = false;
+  /// Allow rename of virtual method hierarchies.
+  /// Disable to support broken index implementations with missing relations.
+  /// FIXME: fix those implementations and remove this option.
+  bool RenameVirtual = true;
 };
 
 struct RenameInputs {



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


[PATCH] D133440: [clangd] Allow programmatically disabling rename of virtual method hierarchies.

2022-09-19 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 rGe42441835827: [clangd] Allow programmatically disabling 
rename of virtual method hierarchies. (authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D133440?vs=458520&id=461211#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133440

Files:
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Rename.h


Index: clang-tools-extra/clangd/refactor/Rename.h
===
--- clang-tools-extra/clangd/refactor/Rename.h
+++ clang-tools-extra/clangd/refactor/Rename.h
@@ -26,6 +26,10 @@
   size_t LimitFiles = 50;
   /// If true, format the rename edits, only meaningful in ClangdServer layer.
   bool WantFormat = false;
+  /// Allow rename of virtual method hierarchies.
+  /// Disable to support broken index implementations with missing relations.
+  /// FIXME: fix those implementations and remove this option.
+  bool RenameVirtual = true;
 };
 
 struct RenameInputs {
Index: clang-tools-extra/clangd/refactor/Rename.cpp
===
--- clang-tools-extra/clangd/refactor/Rename.cpp
+++ clang-tools-extra/clangd/refactor/Rename.cpp
@@ -181,8 +181,15 @@
 
 llvm::Optional renameable(const NamedDecl &RenameDecl,
   StringRef MainFilePath,
-  const SymbolIndex *Index) {
+  const SymbolIndex *Index,
+  const RenameOptions& Opts) {
   trace::Span Tracer("Renameable");
+  if (!Opts.RenameVirtual) {
+if (const auto *S = llvm::dyn_cast(&RenameDecl)) {
+  if (S->isVirtual())
+return ReasonToReject::UnsupportedSymbol;
+}
+  }
   // Filter out symbols that are unsupported in both rename modes.
   if (llvm::isa(&RenameDecl))
 return ReasonToReject::UnsupportedSymbol;
@@ -746,7 +753,8 @@
   if (Invalid)
 return makeError(std::move(*Invalid));
 
-  auto Reject = renameable(RenameDecl, RInputs.MainFilePath, RInputs.Index);
+  auto Reject =
+  renameable(RenameDecl, RInputs.MainFilePath, RInputs.Index, Opts);
   if (Reject)
 return makeError(*Reject);
 


Index: clang-tools-extra/clangd/refactor/Rename.h
===
--- clang-tools-extra/clangd/refactor/Rename.h
+++ clang-tools-extra/clangd/refactor/Rename.h
@@ -26,6 +26,10 @@
   size_t LimitFiles = 50;
   /// If true, format the rename edits, only meaningful in ClangdServer layer.
   bool WantFormat = false;
+  /// Allow rename of virtual method hierarchies.
+  /// Disable to support broken index implementations with missing relations.
+  /// FIXME: fix those implementations and remove this option.
+  bool RenameVirtual = true;
 };
 
 struct RenameInputs {
Index: clang-tools-extra/clangd/refactor/Rename.cpp
===
--- clang-tools-extra/clangd/refactor/Rename.cpp
+++ clang-tools-extra/clangd/refactor/Rename.cpp
@@ -181,8 +181,15 @@
 
 llvm::Optional renameable(const NamedDecl &RenameDecl,
   StringRef MainFilePath,
-  const SymbolIndex *Index) {
+  const SymbolIndex *Index,
+  const RenameOptions& Opts) {
   trace::Span Tracer("Renameable");
+  if (!Opts.RenameVirtual) {
+if (const auto *S = llvm::dyn_cast(&RenameDecl)) {
+  if (S->isVirtual())
+return ReasonToReject::UnsupportedSymbol;
+}
+  }
   // Filter out symbols that are unsupported in both rename modes.
   if (llvm::isa(&RenameDecl))
 return ReasonToReject::UnsupportedSymbol;
@@ -746,7 +753,8 @@
   if (Invalid)
 return makeError(std::move(*Invalid));
 
-  auto Reject = renameable(RenameDecl, RInputs.MainFilePath, RInputs.Index);
+  auto Reject =
+  renameable(RenameDecl, RInputs.MainFilePath, RInputs.Index, Opts);
   if (Reject)
 return makeError(*Reject);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D133711: [Sema] Reject array element types whose sizes aren't a multiple of their alignments

2022-09-19 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak added a comment.

I'm going to commit this in a day or two if there are no more comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133711

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


[PATCH] D133993: [HLSL] Remove global ctor/dtor variable for non-lib profile.

2022-09-19 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added a comment.

We should also have a library test case that verifies that the `global_dtors` 
variable is kept.




Comment at: clang/lib/CodeGen/CGHLSLRuntime.h:50
   void annotateHLSLResource(const VarDecl *D, llvm::GlobalVariable *GV);
-  void generateGlobalCtorDtorCalls();
+  void generateGlobalCtorDtorCalls(llvm::Triple &T);
 

You don't need to pass the triple in here. If you have the module, you have the 
triple.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133993

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


[PATCH] D133856: [clang][Interp] Pass initializer through when creating variables

2022-09-19 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133856

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


[PATCH] D133329: [Driver] Add --gcc-install-dir=

2022-09-19 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D133329#3798371 , @mgorny wrote:

> I think you misunderstood me. The aforementioned tests fail if I put 
> `--gcc-install-dir=` in the config file. There is no way to put it in the 
> config file that wouldn't affect these tests right now.

This is unsupported. It's like if you put `-W` in a default config file it may 
change a lot of things. We cannot reasonably support such tests without 
introducing a lot of complexity to a lot of driver tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133329

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


[PATCH] D134189: [CUDA][HIP] Fix new driver crashing when using -save-temps in RDC-mode

2022-09-19 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 created this revision.
jhuber6 added reviewers: tra, yaxunl.
Herald added subscribers: kosarev, mattd, kerbowa, jvesely.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1, MaskRay.
Herald added a reviewer: jdoerfert.
Herald added a project: clang.

Previously when using the `clang-offload-packager` we did not pass the
active offloading kinds. Then in Clang when we attempted to detect when
there was host-offloading action that needed to be embedded in the host
we did not find it. This patch adds the active offloading kinds so we
know when there is input to be embedded.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134189

Files:
  clang/include/clang/Driver/Action.h
  clang/lib/Driver/Action.cpp
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/amdgpu-openmp-toolchain.c
  clang/test/Driver/cuda-bindings.cu
  clang/test/Driver/cuda-phases.cu
  clang/test/Driver/openmp-offload-gpu.c
  clang/test/Driver/openmp-offload.c

Index: clang/test/Driver/openmp-offload.c
===
--- clang/test/Driver/openmp-offload.c
+++ clang/test/Driver/openmp-offload.c
@@ -110,8 +110,8 @@
 // CHK-PHASES-NEXT: 7: backend, {6}, assembler, (device-openmp)
 // CHK-PHASES-NEXT: 8: assembler, {7}, object, (device-openmp)
 // CHK-PHASES-NEXT: 9: offload, "device-openmp (powerpc64-ibm-linux-gnu)" {8}, object
-// CHK-PHASES-NEXT: 10: clang-offload-packager, {9}, image
-// CHK-PHASES-NEXT: 11: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {2}, " (powerpc64-ibm-linux-gnu)" {10}, ir
+// CHK-PHASES-NEXT: 10: clang-offload-packager, {9}, image, (device-openmp)
+// CHK-PHASES-NEXT: 11: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {2}, "device-openmp (powerpc64-ibm-linux-gnu)" {10}, ir
 // CHK-PHASES-NEXT: 12: backend, {11}, assembler, (host-openmp)
 // CHK-PHASES-NEXT: 13: assembler, {12}, object, (host-openmp)
 // CHK-PHASES-NEXT: 14: clang-linker-wrapper, {13}, image, (host-openmp)
@@ -139,8 +139,8 @@
 // CHK-PHASES-FILES-NEXT: 15: backend, {14}, assembler, (device-openmp)
 // CHK-PHASES-FILES-NEXT: 16: assembler, {15}, object, (device-openmp)
 // CHK-PHASES-FILES-NEXT: 17: offload, "device-openmp (powerpc64-ibm-linux-gnu)" {16}, object
-// CHK-PHASES-FILES-NEXT: 18: clang-offload-packager, {10, 17}, image
-// CHK-PHASES-FILES-NEXT: 19: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {3}, " (powerpc64-ibm-linux-gnu)" {18}, ir
+// CHK-PHASES-FILES-NEXT: 18: clang-offload-packager, {10, 17}, image, (device-openmp)
+// CHK-PHASES-FILES-NEXT: 19: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {3}, "device-openmp (powerpc64-ibm-linux-gnu)" {18}, ir
 // CHK-PHASES-FILES-NEXT: 20: backend, {19}, assembler, (host-openmp)
 // CHK-PHASES-FILES-NEXT: 21: assembler, {20}, object, (host-openmp)
 // CHK-PHASES-FILES-NEXT: 22: input, "[[INPUT]]", c, (host-openmp)
@@ -160,8 +160,8 @@
 // CHK-PHASES-FILES-NEXT: 36: backend, {35}, assembler, (device-openmp)
 // CHK-PHASES-FILES-NEXT: 37: assembler, {36}, object, (device-openmp)
 // CHK-PHASES-FILES-NEXT: 38: offload, "device-openmp (powerpc64-ibm-linux-gnu)" {37}, object
-// CHK-PHASES-FILES-NEXT: 39: clang-offload-packager, {31, 38}, image
-// CHK-PHASES-FILES-NEXT: 40: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {24}, " (powerpc64-ibm-linux-gnu)" {39}, ir
+// CHK-PHASES-FILES-NEXT: 39: clang-offload-packager, {31, 38}, image, (device-openmp)
+// CHK-PHASES-FILES-NEXT: 40: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {24}, "device-openmp (powerpc64-ibm-linux-gnu)" {39}, ir
 // CHK-PHASES-FILES-NEXT: 41: backend, {40}, assembler, (host-openmp)
 // CHK-PHASES-FILES-NEXT: 42: assembler, {41}, object, (host-openmp)
 // CHK-PHASES-FILES-NEXT: 43: clang-linker-wrapper, {0, 21, 42}, image, (host-openmp)
Index: clang/test/Driver/openmp-offload-gpu.c
===
--- clang/test/Driver/openmp-offload-gpu.c
+++ clang/test/Driver/openmp-offload-gpu.c
@@ -258,7 +258,7 @@
 // CHECK-PHASES: 8: assembler, {7}, object, (device-openmp)
 // CHECK-PHASES: 9: offload, "device-openmp (nvptx64-nvidia-cuda)" {8}, object
 // CHECK-PHASES: 10: clang-offload-packager, {9}, image
-// CHECK-PHASES: 11: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, " (x86_64-unknown-linux-gnu)" {10}, ir
+// CHECK-PHASES: 11: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (x86_64-unknown-linux-gnu)" {10}, ir
 // CHECK-PHASES: 12: backend, {11}, assembler, (host-openmp)
 // CHECK-PHASES: 13: assembler, {12}, object, (host-openmp)
 // CHECK-PHASES: 14: clang-linker-wrapper, {13}, image, (host-openmp)
Index: clang/test/Driver/cuda-phases.cu
===
--- clang/test/Driver/cuda-phases.cu
+++ clang/test/Driver/cuda-phases.cu
@@ -238,8 +238,8 @@
 // NEW-DRIVER-RDC-NEXT: 12: backend, {11}, assembler, (device-cuda, sm_70)
 // NEW-DRIVER-RDC-NEXT: 13:

[PATCH] D133856: [clang][Interp] Pass initializer through when creating variables

2022-09-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane accepted this revision.
erichkeane added a comment.
This revision is now accepted and ready to land.

Seems fine to me


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133856

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


[PATCH] D133119: [clang-tidy] Add checker 'bugprone-suspicious-realloc-usage'.

2022-09-19 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added reviewers: steakhal, martong.
balazske added a comment.
Herald added a subscriber: rnkovacs.

I see that there are problems to solve with this patch. If a global variable is 
used at `realloc` or the pointer is a function parameter, it may have aliases 
that are not checkable. In the function code it is possible to detect aliasing. 
If all these cases are eliminated probably not much is left that is detected by 
the check, but we can test it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133119

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


[PATCH] D134191: [clang] Make config-related options CoreOptions

2022-09-19 Thread Michał Górny via Phabricator via cfe-commits
mgorny created this revision.
mgorny added reviewers: sepavloff, MaskRay, hfinkel.
Herald added a subscriber: StephenFan.
Herald added a project: All.
mgorny requested review of this revision.

Make `--config`, `--no-default-config` and `--config-*-dir` CoreOptions
to enable their availability to all clang driver modes.  This improves
consistency given that the default set of configuration files is
processed independently of mode anyway.


https://reviews.llvm.org/D134191

Files:
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -899,13 +899,13 @@
 def client__name : JoinedOrSeparate<["-"], "client_name">;
 def combine : Flag<["-", "--"], "combine">, Flags<[NoXarchOption, 
Unsupported]>;
 def compatibility__version : JoinedOrSeparate<["-"], "compatibility_version">;
-def config : Separate<["--"], "config">, Flags<[NoXarchOption]>,
+def config : Separate<["--"], "config">, Flags<[NoXarchOption, CoreOption]>,
   HelpText<"Specifies configuration file">;
-def no_default_config : Flag<["--"], "no-default-config">, 
Flags<[NoXarchOption]>,
+def no_default_config : Flag<["--"], "no-default-config">, 
Flags<[NoXarchOption, CoreOption]>,
   HelpText<"Disable loading default configuration files">;
-def config_system_dir_EQ : Joined<["--"], "config-system-dir=">, 
Flags<[NoXarchOption, HelpHidden]>,
+def config_system_dir_EQ : Joined<["--"], "config-system-dir=">, 
Flags<[NoXarchOption, CoreOption, HelpHidden]>,
   HelpText<"System directory for configuration files">;
-def config_user_dir_EQ : Joined<["--"], "config-user-dir=">, 
Flags<[NoXarchOption, HelpHidden]>,
+def config_user_dir_EQ : Joined<["--"], "config-user-dir=">, 
Flags<[NoXarchOption, CoreOption, HelpHidden]>,
   HelpText<"User directory for configuration files">;
 def coverage : Flag<["-", "--"], "coverage">, Group, 
Flags<[CoreOption]>;
 def cpp_precomp : Flag<["-"], "cpp-precomp">, Group;


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -899,13 +899,13 @@
 def client__name : JoinedOrSeparate<["-"], "client_name">;
 def combine : Flag<["-", "--"], "combine">, Flags<[NoXarchOption, Unsupported]>;
 def compatibility__version : JoinedOrSeparate<["-"], "compatibility_version">;
-def config : Separate<["--"], "config">, Flags<[NoXarchOption]>,
+def config : Separate<["--"], "config">, Flags<[NoXarchOption, CoreOption]>,
   HelpText<"Specifies configuration file">;
-def no_default_config : Flag<["--"], "no-default-config">, Flags<[NoXarchOption]>,
+def no_default_config : Flag<["--"], "no-default-config">, Flags<[NoXarchOption, CoreOption]>,
   HelpText<"Disable loading default configuration files">;
-def config_system_dir_EQ : Joined<["--"], "config-system-dir=">, Flags<[NoXarchOption, HelpHidden]>,
+def config_system_dir_EQ : Joined<["--"], "config-system-dir=">, Flags<[NoXarchOption, CoreOption, HelpHidden]>,
   HelpText<"System directory for configuration files">;
-def config_user_dir_EQ : Joined<["--"], "config-user-dir=">, Flags<[NoXarchOption, HelpHidden]>,
+def config_user_dir_EQ : Joined<["--"], "config-user-dir=">, Flags<[NoXarchOption, CoreOption, HelpHidden]>,
   HelpText<"User directory for configuration files">;
 def coverage : Flag<["-", "--"], "coverage">, Group, Flags<[CoreOption]>;
 def cpp_precomp : Flag<["-"], "cpp-precomp">, Group;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D134191: [clang] Make config-related options CoreOptions

2022-09-19 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay accepted this revision.
MaskRay added a comment.
This revision is now accepted and ready to land.

Thanks!


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

https://reviews.llvm.org/D134191

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


[PATCH] D134191: [clang] Make config-related options CoreOptions

2022-09-19 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

They don't need to be `NoXarchOption` if I am not mistaken.


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

https://reviews.llvm.org/D134191

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


[PATCH] D133711: [Sema] Reject array element types whose sizes aren't a multiple of their alignments

2022-09-19 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision.
rnk added a comment.

Sound like a good plan. 👍


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133711

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


[PATCH] D133920: [X86][fastcall][vectorcall] Move capability check before free register update

2022-09-19 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

lgtm, thanks for the fix!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133920

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


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

2022-09-19 Thread Xiang Li via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
python3kgae marked an inline comment as done.
Closed by commit rG649a59712ffb: [clang] Allow vector of BitInt (authored by 
python3kgae).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133634

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGenCXX/ext-int-vector-abi.cpp
  clang/test/CodeGenCXX/ext-int.cpp
  clang/test/Sema/builtin-classify-type.c
  clang/test/SemaCXX/ext-int.cpp

Index: clang/test/SemaCXX/ext-int.cpp
===
--- clang/test/SemaCXX/ext-int.cpp
+++ clang/test/SemaCXX/ext-int.cpp
@@ -84,10 +84,22 @@
 };
 
 // Reject vector types:
-// expected-error@+1{{invalid vector element type '_BitInt(32)'}}
-typedef _BitInt(32) __attribute__((vector_size(16))) VecTy;
-// expected-error@+1{{invalid vector element type '_BitInt(32)'}}
-typedef _BitInt(32) __attribute__((ext_vector_type(32))) OtherVecTy;
+// expected-error@+1{{'_BitInt' vector element width must be at least as wide as 'CHAR_BIT'}}
+typedef _BitInt(2) __attribute__((vector_size(16))) VecTy;
+// expected-error@+1{{'_BitInt' vector element width must be at least as wide as 'CHAR_BIT'}}
+typedef _BitInt(2) __attribute__((ext_vector_type(32))) OtherVecTy;
+// expected-error@+1{{'_BitInt' vector element width must be at least as wide as 'CHAR_BIT'}}
+typedef _BitInt(4) __attribute__((vector_size(16))) VecTy2;
+// expected-error@+1{{'_BitInt' vector element width must be at least as wide as 'CHAR_BIT'}}
+typedef _BitInt(4) __attribute__((ext_vector_type(32))) OtherVecTy2;
+// expected-error@+1{{'_BitInt' vector element width must be at least as wide as 'CHAR_BIT'}}
+typedef _BitInt(5) __attribute__((vector_size(16))) VecTy3;
+// expected-error@+1{{'_BitInt' vector element width must be at least as wide as 'CHAR_BIT'}}
+typedef _BitInt(5) __attribute__((ext_vector_type(32))) OtherVecTy3;
+// expected-error@+1{{'_BitInt' vector element width must be a power of 2}}
+typedef _BitInt(37) __attribute__((vector_size(16))) VecTy4;
+// expected-error@+1{{'_BitInt' vector element width must be a power of 2}}
+typedef _BitInt(37) __attribute__((ext_vector_type(32))) OtherVecTy4;
 
 // Allow _Complex:
 _Complex _BitInt(3) Cmplx;
Index: clang/test/Sema/builtin-classify-type.c
===
--- clang/test/Sema/builtin-classify-type.c
+++ clang/test/Sema/builtin-classify-type.c
@@ -29,6 +29,23 @@
   __attribute__((vector_size(16))) int vec;
   typedef __attribute__((ext_vector_type(4))) int evec_t;
   evec_t evec;
+  typedef _BitInt(8) int8_t3 __attribute__((ext_vector_type(3)));
+  int8_t3 t3;
+  typedef _BitInt(16) int16_t3 __attribute__((ext_vector_type(4)));
+  int16_t3 t4;
+  typedef _BitInt(32) int32_t3 __attribute__((ext_vector_type(5)));
+  int32_t3 t5;
+  typedef _BitInt(64) int64_t3 __attribute__((ext_vector_type(6)));
+  int64_t3 t6;
+  typedef _BitInt(8) vint8_t3 __attribute__((vector_size(3)));
+  vint8_t3 vt3;
+  typedef _BitInt(16) vint16_t3 __attribute__((vector_size(4)));
+  vint16_t3 vt4;
+  typedef _BitInt(32) vint32_t3 __attribute__((vector_size(8)));
+  vint32_t3 vt5;
+  typedef _BitInt(64) vint64_t3 __attribute__((vector_size(16)));
+  vint64_t3 vt6;
+
   _Atomic int atomic_i;
   _Atomic double atomic_d;
   _Complex int complex_i;
Index: clang/test/CodeGenCXX/ext-int.cpp
===
--- clang/test/CodeGenCXX/ext-int.cpp
+++ clang/test/CodeGenCXX/ext-int.cpp
@@ -129,6 +129,9 @@
   return 0;
 }
 
+typedef unsigned _BitInt(16) uint16_t4 __attribute__((ext_vector_type(4)));
+typedef _BitInt(32) vint32_t8 __attribute__((vector_size(32)));
+
 template
 void ManglingTestTemplateParam(T&);
 template<_BitInt(99) T>
@@ -136,7 +139,6 @@
 template 
 auto ManglingDependent() -> decltype(_BitInt(N){});
 
-
 void ManglingInstantiator() {
   // LIN: define{{.*}} void @_Z20ManglingInstantiatorv()
   // WIN: define dso_local void @"?ManglingInstantiator@@YAXXZ"()
@@ -156,6 +158,12 @@
   // LIN: call signext i4 @_Z17ManglingDependentILi4EEDTtlDBT__EEv()
   // WIN64: call i4 @"??$ManglingDependent@$03@@YAU?$_BitInt@$03@__clang@@XZ"()
   // WIN32: call signext i4 @"??$ManglingDependent@$03@@YAU?$_BitInt@$03@__clang@@XZ"()
+  uint16_t4 V;
+  ManglingTestTemplateParam(V);
+  // LIN: call void @_Z25ManglingTestTemplateParamIDv4_DU16_EvRT_(<4 x i16>*
+  // WIN64: call void @"??$ManglingTestTemplateParam@T?$__vector@U?$_UBitInt@$0BA@@__clang@@$03@__clangYAXAEAT?$__vector@U?$_UBitInt@$0BA@@__clang@@$03@__clang@@@Z"(<4 x i16>*
+  // WIN32: call void @"??$ManglingTestTemplateParam@T?$__vector@U?$_UBitInt@$0BA@@__clang@@$03@__clangYAXAAT?$__vector@U?$_UBitInt@$0BA@@__clang@@$03@__clang@@@Z"(<4 x i16>*
+
 }
 
 void Ta

[clang] 649a597 - [clang] Allow vector of BitInt

2022-09-19 Thread Xiang Li via cfe-commits

Author: Xiang Li
Date: 2022-09-19T09:26:56-07:00
New Revision: 649a59712ffbc937174268d04ee9a8885f572e2a

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

LOG: [clang] Allow vector of BitInt

Remove check which disable BitInt as element type for ext_vector.

Enabling it for HLSL to use _BitInt(16) as 16bit int at 
https://reviews.llvm.org/D133668

Reviewed By: erichkeane

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

Added: 
clang/test/CodeGenCXX/ext-int-vector-abi.cpp

Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/AST/ASTContext.cpp
clang/lib/AST/MicrosoftMangle.cpp
clang/lib/Sema/SemaType.cpp
clang/test/CodeGenCXX/ext-int.cpp
clang/test/Sema/builtin-classify-type.c
clang/test/SemaCXX/ext-int.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 97ccc2a98c93b..673aba962b7fe 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3021,6 +3021,9 @@ def err_attribute_too_many_arguments : Error<
 def err_attribute_too_few_arguments : Error<
   "%0 attribute takes at least %1 argument%s1">;
 def err_attribute_invalid_vector_type : Error<"invalid vector element type 
%0">;
+def err_attribute_invalid_bitint_vector_type : Error<
+  "'_BitInt' vector element width must be %select{a power of 2|"
+  "at least as wide as 'CHAR_BIT'}0">;
 def err_attribute_invalid_matrix_type : Error<"invalid matrix element type 
%0">;
 def err_attribute_bad_neon_vector_size : Error<
   "Neon vector size must be 64 or 128 bits">;

diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index ab141789416ca..622bad78e59a8 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -4019,7 +4019,11 @@ QualType ASTContext::getScalableVectorType(QualType 
EltTy,
 /// the specified element type and size. VectorType must be a built-in type.
 QualType ASTContext::getVectorType(QualType vecType, unsigned NumElts,
VectorType::VectorKind VecKind) const {
-  assert(vecType->isBuiltinType());
+  assert(vecType->isBuiltinType() ||
+ (vecType->isBitIntType() &&
+  // Only support _BitInt elements with byte-sized power of 2 NumBits.
+  llvm::isPowerOf2_32(vecType->getAs()->getNumBits()) &&
+  vecType->getAs()->getNumBits() >= 8));
 
   // Check if we've already instantiated a vector of this type.
   llvm::FoldingSetNodeID ID;
@@ -4087,9 +4091,13 @@ ASTContext::getDependentVectorType(QualType VecType, 
Expr *SizeExpr,
 
 /// getExtVectorType - Return the unique reference to an extended vector type 
of
 /// the specified element type and size. VectorType must be a built-in type.
-QualType
-ASTContext::getExtVectorType(QualType vecType, unsigned NumElts) const {
-  assert(vecType->isBuiltinType() || vecType->isDependentType());
+QualType ASTContext::getExtVectorType(QualType vecType,
+  unsigned NumElts) const {
+  assert(vecType->isBuiltinType() || vecType->isDependentType() ||
+ (vecType->isBitIntType() &&
+  // Only support _BitInt elements with byte-sized power of 2 NumBits.
+  llvm::isPowerOf2_32(vecType->getAs()->getNumBits()) &&
+  vecType->getAs()->getNumBits() >= 8));
 
   // Check if we've already instantiated a vector of this type.
   llvm::FoldingSetNodeID ID;

diff  --git a/clang/lib/AST/MicrosoftMangle.cpp 
b/clang/lib/AST/MicrosoftMangle.cpp
index e58fedb6fa54c..bc69d85e49c96 100644
--- a/clang/lib/AST/MicrosoftMangle.cpp
+++ b/clang/lib/AST/MicrosoftMangle.cpp
@@ -3073,14 +3073,17 @@ bool 
MicrosoftCXXNameMangler::isArtificialTagType(QualType T) const {
 
 void MicrosoftCXXNameMangler::mangleType(const VectorType *T, Qualifiers Quals,
  SourceRange Range) {
-  const BuiltinType *ET = T->getElementType()->getAs();
-  assert(ET && "vectors with non-builtin elements are unsupported");
+  QualType EltTy = T->getElementType();
+  const BuiltinType *ET = EltTy->getAs();
+  const BitIntType *BitIntTy = EltTy->getAs();
+  assert((ET || BitIntTy) &&
+ "vectors with non-builtin/_BitInt elements are unsupported");
   uint64_t Width = getASTContext().getTypeSize(T);
   // Pattern match exactly the typedefs in our intrinsic headers.  Anything 
that
   // doesn't match the Intel types uses a custom mangling below.
   size_t OutSizeBefore = Out.tell();
   if (!isa(T)) {
-if (getASTContext().getTargetInfo().getTriple().isX86()) {
+if (getASTContext().getTargetInfo().getTriple().isX86() && ET) {
   if (Width == 64 && ET->getKind() == BuiltinType::LongLong) {
 mangleArtificialTagType(

[PATCH] D133589: [clang-format] JSON formatting add new option for controlling newlines in json arrays

2022-09-19 Thread MyDeveloperDay via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG95b394711106: [clang-format] JSON formatting add new option 
for controlling newlines in json… (authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133589

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTestJson.cpp

Index: clang/unittests/Format/FormatTestJson.cpp
===
--- clang/unittests/Format/FormatTestJson.cpp
+++ clang/unittests/Format/FormatTestJson.cpp
@@ -159,6 +159,27 @@
"]");
 }
 
+TEST_F(FormatTestJson, JsonArrayOneLine) {
+  FormatStyle Style = getLLVMStyle(FormatStyle::LK_Json);
+  Style.BreakArrays = false;
+  Style.SpacesInContainerLiterals = false;
+  verifyFormat("[]", Style);
+  verifyFormat("[1]", Style);
+  verifyFormat("[1, 2]", Style);
+  verifyFormat("[1, 2, 3]", Style);
+  verifyFormat("[1, 2, 3, 4]", Style);
+  verifyFormat("[1, 2, 3, 4, 5]", Style);
+
+  verifyFormat("[\n"
+   "  1,\n"
+   "  2,\n"
+   "  {\n"
+   "A: 1\n"
+   "  }\n"
+   "]",
+   Style);
+}
+
 TEST_F(FormatTestJson, JsonNoStringSplit) {
   FormatStyle Style = getLLVMStyle(FormatStyle::LK_Json);
   Style.IndentWidth = 4;
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -4401,18 +4401,22 @@
 // }
 if (Left.is(TT_DictLiteral) && Left.is(tok::l_brace))
   return true;
-// Always break after a JSON array opener.
-// [
-// ]
-if (Left.is(TT_ArrayInitializerLSquare) && Left.is(tok::l_square) &&
-!Right.is(tok::r_square)) {
-  return true;
+// Always break after a JSON array opener based on BreakArrays.
+if ((Left.is(TT_ArrayInitializerLSquare) && Left.is(tok::l_square) &&
+ Right.isNot(tok::r_square)) ||
+Left.is(tok::comma)) {
+  if (Right.is(tok::l_brace))
+return true;
+  // scan to the right if an we see an object or an array inside
+  // then break.
+  for (const auto *Tok = &Right; Tok; Tok = Tok->Next) {
+if (Tok->isOneOf(tok::l_brace, tok::l_square))
+  return true;
+if (Tok->isOneOf(tok::r_brace, tok::r_square))
+  break;
+  }
+  return Style.BreakArrays;
 }
-// Always break after successive entries.
-// 1,
-// 2
-if (Left.is(tok::comma))
-  return true;
   }
 
   // If the last token before a '}', ']', or ')' is a comma or a trailing
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -728,6 +728,7 @@
 
 IO.mapOptional("BreakAfterJavaFieldAnnotations",
Style.BreakAfterJavaFieldAnnotations);
+IO.mapOptional("BreakArrays", Style.BreakArrays);
 IO.mapOptional("BreakStringLiterals", Style.BreakStringLiterals);
 IO.mapOptional("ColumnLimit", Style.ColumnLimit);
 IO.mapOptional("CommentPragmas", Style.CommentPragmas);
@@ -1249,6 +1250,7 @@
   LLVMStyle.EmptyLineAfterAccessModifier = FormatStyle::ELAAMS_Never;
   LLVMStyle.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_LogicalBlock;
   LLVMStyle.ExperimentalAutoDetectBinPacking = false;
+  LLVMStyle.BreakArrays = true;
   LLVMStyle.PackConstructorInitializers = FormatStyle::PCIS_BinPack;
   LLVMStyle.FixNamespaceComments = true;
   LLVMStyle.ForEachMacros.push_back("foreach");
Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -872,6 +872,23 @@
   /// \version 3.7
   bool BinPackParameters;
 
+  /// If ``true``, clang-format will always break after a Json array `[`
+  /// otherwise it will scan until the closing `]` to determine if it should add
+  /// newlines between elements (prettier compatible).
+  ///
+  /// NOTE: This is currently only for formatting JSON.
+  /// \code
+  ///true:  false:
+  ///[  vs.  [1, 2, 3, 4]
+  ///  1,
+  ///  2,
+  ///  3,
+  ///  4
+  ///]
+  /// \endcode
+  /// \version 16
+  bool BreakArrays;
+
   /// The style of wrapping parameters on the same line (bin-packed) or
   /// on one line each.
   enum BinPackStyle : int8_t {
@@ -3878,6 +3895,7 @@
AttributeMacros == R.AttributeMacros &&
BinPackArguments == R.BinPackArguments &&
BinPackParameters == R.BinPackParameters &&
+   BreakArrays == R.BreakArrays &&
  

[clang] 95b3947 - [clang-format] JSON formatting add new option for controlling newlines in json arrays

2022-09-19 Thread via cfe-commits

Author: mydeveloperday
Date: 2022-09-19T17:54:39+01:00
New Revision: 95b39471110680f609cf56f5babf031a1c855d64

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

LOG: [clang-format] JSON formatting add new option for controlling newlines in 
json arrays

Working in a mixed environment of both vscode/vim with a team configured 
prettier configuration, this can leave clang-format and prettier fighting each 
other over the formatting of arrays, both simple arrays of elements.

This review aims to add some "control knobs" to the Json formatting in 
clang-format to help align the two tools so they can be used interchangeably.

This will allow simply arrays `[1, 2, 3]` to remain on a single line but will 
break those arrays based on context within that array.

Happy to change the name of the option (this is the third name I tried)

Reviewed By: HazardyKnusperkeks, owenpan

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

Added: 


Modified: 
clang/docs/ClangFormatStyleOptions.rst
clang/include/clang/Format/Format.h
clang/lib/Format/Format.cpp
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTestJson.cpp

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index 01ebbd72aae44..3be291578828d 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -1698,6 +1698,23 @@ the configuration (without a prefix: ``Auto``).
  @Mock
  DataLoad loader;
 
+**BreakArrays** (``Boolean``) :versionbadge:`clang-format 16`
+  If ``true``, clang-format will always break after a Json array `[`
+  otherwise it will scan until the closing `]` to determine if it should add
+  newlines between elements (prettier compatible).
+
+  NOTE: This is currently only for formatting JSON.
+
+  .. code-block:: c++
+
+ true:  false:
+ [  vs.  [1, 2, 3, 4]
+   1,
+   2,
+   3,
+   4
+ ]
+
 **BreakBeforeBinaryOperators** (``BinaryOperatorStyle``) 
:versionbadge:`clang-format 3.6`
   The way to wrap binary operators.
 

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 818dbe0c89c78..c8b22f5ebde06 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -872,6 +872,23 @@ struct FormatStyle {
   /// \version 3.7
   bool BinPackParameters;
 
+  /// If ``true``, clang-format will always break after a Json array `[`
+  /// otherwise it will scan until the closing `]` to determine if it should 
add
+  /// newlines between elements (prettier compatible).
+  ///
+  /// NOTE: This is currently only for formatting JSON.
+  /// \code
+  ///true:  false:
+  ///[  vs.  [1, 2, 3, 4]
+  ///  1,
+  ///  2,
+  ///  3,
+  ///  4
+  ///]
+  /// \endcode
+  /// \version 16
+  bool BreakArrays;
+
   /// The style of wrapping parameters on the same line (bin-packed) or
   /// on one line each.
   enum BinPackStyle : int8_t {
@@ -3878,6 +3895,7 @@ struct FormatStyle {
AttributeMacros == R.AttributeMacros &&
BinPackArguments == R.BinPackArguments &&
BinPackParameters == R.BinPackParameters &&
+   BreakArrays == R.BreakArrays &&
BreakBeforeBinaryOperators == R.BreakBeforeBinaryOperators &&
BreakBeforeBraces == R.BreakBeforeBraces &&
BreakBeforeConceptDeclarations == R.BreakBeforeConceptDeclarations 
&&

diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 0327a7ccb22ea..58d5fc1f8c865 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -728,6 +728,7 @@ template <> struct MappingTraits {
 
 IO.mapOptional("BreakAfterJavaFieldAnnotations",
Style.BreakAfterJavaFieldAnnotations);
+IO.mapOptional("BreakArrays", Style.BreakArrays);
 IO.mapOptional("BreakStringLiterals", Style.BreakStringLiterals);
 IO.mapOptional("ColumnLimit", Style.ColumnLimit);
 IO.mapOptional("CommentPragmas", Style.CommentPragmas);
@@ -1249,6 +1250,7 @@ FormatStyle getLLVMStyle(FormatStyle::LanguageKind 
Language) {
   LLVMStyle.EmptyLineAfterAccessModifier = FormatStyle::ELAAMS_Never;
   LLVMStyle.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_LogicalBlock;
   LLVMStyle.ExperimentalAutoDetectBinPacking = false;
+  LLVMStyle.BreakArrays = true;
   LLVMStyle.PackConstructorInitializers = FormatStyle::PCIS_BinPack;
   LLVMStyle.FixNamespaceComments = true;
   LLVMStyle.ForEachMacros.push_back("foreach");

diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index e530120fa4454..21c

[PATCH] D134191: [clang] Make config-related options CoreOptions

2022-09-19 Thread Michał Górny via Phabricator via cfe-commits
mgorny added a comment.

In D134191#3799841 , @MaskRay wrote:

> They don't need to be `NoXarchOption` if I am not mistaken.

I don't know about that. The comment on top says "The option is a "driver"-only 
option, and should not be forwarded to other tools via `-Xarch` options.". 
Well, it's processed by driver only, isn't it?


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

https://reviews.llvm.org/D134191

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


[clang] daebf2c - [clang] Make config-related options CoreOptions

2022-09-19 Thread Michał Górny via cfe-commits

Author: Michał Górny
Date: 2022-09-19T18:58:09+02:00
New Revision: daebf2c13ce27ac6a7403525cc7fcbc063eb892e

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

LOG: [clang] Make config-related options CoreOptions

Make `--config`, `--no-default-config` and `--config-*-dir` CoreOptions
to enable their availability to all clang driver modes.  This improves
consistency given that the default set of configuration files is
processed independently of mode anyway.

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 8dea1a01c1f89..67ceaf5bf0f2a 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -899,13 +899,13 @@ def cl_ext_EQ : CommaJoined<["-"], "cl-ext=">, 
Group, Flags<[CC1Op
 def client__name : JoinedOrSeparate<["-"], "client_name">;
 def combine : Flag<["-", "--"], "combine">, Flags<[NoXarchOption, 
Unsupported]>;
 def compatibility__version : JoinedOrSeparate<["-"], "compatibility_version">;
-def config : Separate<["--"], "config">, Flags<[NoXarchOption]>,
+def config : Separate<["--"], "config">, Flags<[NoXarchOption, CoreOption]>,
   HelpText<"Specifies configuration file">;
-def no_default_config : Flag<["--"], "no-default-config">, 
Flags<[NoXarchOption]>,
+def no_default_config : Flag<["--"], "no-default-config">, 
Flags<[NoXarchOption, CoreOption]>,
   HelpText<"Disable loading default configuration files">;
-def config_system_dir_EQ : Joined<["--"], "config-system-dir=">, 
Flags<[NoXarchOption, HelpHidden]>,
+def config_system_dir_EQ : Joined<["--"], "config-system-dir=">, 
Flags<[NoXarchOption, CoreOption, HelpHidden]>,
   HelpText<"System directory for configuration files">;
-def config_user_dir_EQ : Joined<["--"], "config-user-dir=">, 
Flags<[NoXarchOption, HelpHidden]>,
+def config_user_dir_EQ : Joined<["--"], "config-user-dir=">, 
Flags<[NoXarchOption, CoreOption, HelpHidden]>,
   HelpText<"User directory for configuration files">;
 def coverage : Flag<["-", "--"], "coverage">, Group, 
Flags<[CoreOption]>;
 def cpp_precomp : Flag<["-"], "cpp-precomp">, Group;



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


[PATCH] D134191: [clang] Make config-related options CoreOptions

2022-09-19 Thread Michał Górny 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 rGdaebf2c13ce2: [clang] Make config-related options 
CoreOptions (authored by mgorny).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134191

Files:
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -899,13 +899,13 @@
 def client__name : JoinedOrSeparate<["-"], "client_name">;
 def combine : Flag<["-", "--"], "combine">, Flags<[NoXarchOption, 
Unsupported]>;
 def compatibility__version : JoinedOrSeparate<["-"], "compatibility_version">;
-def config : Separate<["--"], "config">, Flags<[NoXarchOption]>,
+def config : Separate<["--"], "config">, Flags<[NoXarchOption, CoreOption]>,
   HelpText<"Specifies configuration file">;
-def no_default_config : Flag<["--"], "no-default-config">, 
Flags<[NoXarchOption]>,
+def no_default_config : Flag<["--"], "no-default-config">, 
Flags<[NoXarchOption, CoreOption]>,
   HelpText<"Disable loading default configuration files">;
-def config_system_dir_EQ : Joined<["--"], "config-system-dir=">, 
Flags<[NoXarchOption, HelpHidden]>,
+def config_system_dir_EQ : Joined<["--"], "config-system-dir=">, 
Flags<[NoXarchOption, CoreOption, HelpHidden]>,
   HelpText<"System directory for configuration files">;
-def config_user_dir_EQ : Joined<["--"], "config-user-dir=">, 
Flags<[NoXarchOption, HelpHidden]>,
+def config_user_dir_EQ : Joined<["--"], "config-user-dir=">, 
Flags<[NoXarchOption, CoreOption, HelpHidden]>,
   HelpText<"User directory for configuration files">;
 def coverage : Flag<["-", "--"], "coverage">, Group, 
Flags<[CoreOption]>;
 def cpp_precomp : Flag<["-"], "cpp-precomp">, Group;


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -899,13 +899,13 @@
 def client__name : JoinedOrSeparate<["-"], "client_name">;
 def combine : Flag<["-", "--"], "combine">, Flags<[NoXarchOption, Unsupported]>;
 def compatibility__version : JoinedOrSeparate<["-"], "compatibility_version">;
-def config : Separate<["--"], "config">, Flags<[NoXarchOption]>,
+def config : Separate<["--"], "config">, Flags<[NoXarchOption, CoreOption]>,
   HelpText<"Specifies configuration file">;
-def no_default_config : Flag<["--"], "no-default-config">, Flags<[NoXarchOption]>,
+def no_default_config : Flag<["--"], "no-default-config">, Flags<[NoXarchOption, CoreOption]>,
   HelpText<"Disable loading default configuration files">;
-def config_system_dir_EQ : Joined<["--"], "config-system-dir=">, Flags<[NoXarchOption, HelpHidden]>,
+def config_system_dir_EQ : Joined<["--"], "config-system-dir=">, Flags<[NoXarchOption, CoreOption, HelpHidden]>,
   HelpText<"System directory for configuration files">;
-def config_user_dir_EQ : Joined<["--"], "config-user-dir=">, Flags<[NoXarchOption, HelpHidden]>,
+def config_user_dir_EQ : Joined<["--"], "config-user-dir=">, Flags<[NoXarchOption, CoreOption, HelpHidden]>,
   HelpText<"User directory for configuration files">;
 def coverage : Flag<["-", "--"], "coverage">, Group, Flags<[CoreOption]>;
 def cpp_precomp : Flag<["-"], "cpp-precomp">, Group;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2022-09-19 Thread Xiang Li via Phabricator via cfe-commits
python3kgae updated this revision to Diff 461251.
python3kgae added a comment.

Rebase and update test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133668

Files:
  clang/lib/Basic/Targets/DirectX.h
  clang/lib/Headers/hlsl/hlsl_basic_types.h
  clang/test/CodeGenHLSL/basic_types.hlsl
  clang/test/CodeGenHLSL/builtins/abs.hlsl
  clang/test/CodeGenHLSL/int16_t_add.hlsl


Index: clang/test/CodeGenHLSL/int16_t_add.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/int16_t_add.hlsl
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -D__HLSL_ENABLE_16_BIT \
+// RUN:   -emit-llvm -disable-llvm-passes -O3 -o - | FileCheck %s
+
+// Make sure generate i16 add.
+// CHECK: add nsw i16 %
+int16_t add(int16_t a, int16_t b) {
+  return a + b;
+}
+// CHECK: define noundef <2 x i16> @
+// CHECK: add <2 x i16>
+int16_t2 add(int16_t2 a, int16_t2 b) {
+  return a + b;
+}
+// CHECK: define noundef <3 x i16> @
+// CHECK: add <3 x i16>
+int16_t3 add(int16_t3 a, int16_t3 b) {
+  return a + b;
+}
+// CHECK: define noundef <4 x i16> @
+// CHECK: add <4 x i16>
+int16_t4 add(int16_t4 a, int16_t4 b) {
+  return a + b;
+}
Index: clang/test/CodeGenHLSL/builtins/abs.hlsl
===
--- clang/test/CodeGenHLSL/builtins/abs.hlsl
+++ clang/test/CodeGenHLSL/builtins/abs.hlsl
@@ -7,8 +7,7 @@
 
 
 // CHECK: define noundef signext i16 @
-// FIXME: int16_t is promoted to i32 now. Change to abs.i16 once it is fixed.
-// CHECK: call i32 @llvm.abs.i32(
+// CHECK: call i16 @llvm.abs.i16(
 int16_t test_abs_int16_t ( int16_t p0 ) {
   return abs ( p0 );
 }
Index: clang/test/CodeGenHLSL/basic_types.hlsl
===
--- clang/test/CodeGenHLSL/basic_types.hlsl
+++ clang/test/CodeGenHLSL/basic_types.hlsl
@@ -3,17 +3,17 @@
 // RUN:   -emit-llvm -disable-llvm-passes -o - | FileCheck %s
 
 
-// CHECK:"?uint16_t_Val@@3GA" = global i16 0, align 2
-// CHECK:"?int16_t_Val@@3FA" = global i16 0, align 2
+// CHECK:"?uint16_t_Val@@3U?$_UBitInt@$0BA@@__clang@@A" = global i16 0, align 2
+// CHECK:"?int16_t_Val@@3U?$_BitInt@$0BA@@__clang@@A" = global i16 0, align 2
 // CHECK:"?uint_Val@@3IA" = global i32 0, align 4
 // CHECK:"?uint64_t_Val@@3KA" = global i64 0, align 8
 // CHECK:"?int64_t_Val@@3JA" = global i64 0, align 8
-// CHECK:"?int16_t2_Val@@3T?$__vector@F$01@__clang@@A" = global <2 x i16> 
zeroinitializer, align 4
-// CHECK:"?int16_t3_Val@@3T?$__vector@F$02@__clang@@A" = global <3 x i16> 
zeroinitializer, align 8
-// CHECK:"?int16_t4_Val@@3T?$__vector@F$03@__clang@@A" = global <4 x i16> 
zeroinitializer, align 8
-// CHECK:"?uint16_t2_Val@@3T?$__vector@G$01@__clang@@A" = global <2 x i16> 
zeroinitializer, align 4
-// CHECK:"?uint16_t3_Val@@3T?$__vector@G$02@__clang@@A" = global <3 x i16> 
zeroinitializer, align 8
-// CHECK:"?uint16_t4_Val@@3T?$__vector@G$03@__clang@@A" = global <4 x i16> 
zeroinitializer, align 8
+// 
CHECK:"?int16_t2_Val@@3T?$__vector@U?$_BitInt@$0BA@@__clang@@$01@__clang@@A" = 
global <2 x i16> zeroinitializer, align 4
+// 
CHECK:"?int16_t3_Val@@3T?$__vector@U?$_BitInt@$0BA@@__clang@@$02@__clang@@A" = 
global <3 x i16> zeroinitializer, align 8
+// 
CHECK:"?int16_t4_Val@@3T?$__vector@U?$_BitInt@$0BA@@__clang@@$03@__clang@@A" = 
global <4 x i16> zeroinitializer, align 8
+// 
CHECK:"?uint16_t2_Val@@3T?$__vector@U?$_UBitInt@$0BA@@__clang@@$01@__clang@@A" 
= global <2 x i16> zeroinitializer, align 4
+// 
CHECK:"?uint16_t3_Val@@3T?$__vector@U?$_UBitInt@$0BA@@__clang@@$02@__clang@@A" 
= global <3 x i16> zeroinitializer, align 8
+// 
CHECK:"?uint16_t4_Val@@3T?$__vector@U?$_UBitInt@$0BA@@__clang@@$03@__clang@@A" 
= global <4 x i16> zeroinitializer, align 8
 // CHECK:"?int2_Val@@3T?$__vector@H$01@__clang@@A" = global <2 x i32> 
zeroinitializer, align 8
 // CHECK:"?int3_Val@@3T?$__vector@H$02@__clang@@A" = global <3 x i32> 
zeroinitializer, align 16
 // CHECK:"?int4_Val@@3T?$__vector@H$03@__clang@@A" = global <4 x i32> 
zeroinitializer, align 16
Index: clang/lib/Headers/hlsl/hlsl_basic_types.h
===
--- clang/lib/Headers/hlsl/hlsl_basic_types.h
+++ clang/lib/Headers/hlsl/hlsl_basic_types.h
@@ -13,8 +13,8 @@
 
 #ifdef __HLSL_ENABLE_16_BIT
 // 16-bit integer.
-typedef unsigned short uint16_t;
-typedef short int16_t;
+typedef unsigned _BitInt(16) uint16_t;
+typedef _BitInt(16) int16_t;
 #endif
 
 // unsigned 32-bit integer.
Index: clang/lib/Basic/Targets/DirectX.h
===
--- clang/lib/Basic/Targets/DirectX.h
+++ clang/lib/Basic/Targets/DirectX.h
@@ -65,6 +65,7 @@
   void getTargetDefines(const LangOptions &Opts,
 MacroBuilder &Builder) const override;
 
+  bool hasBitIntType() cons

[clang-tools-extra] 8edce2f - [test][clangd] Join back -Xclang and -undef

2022-09-19 Thread Vitaly Buka via cfe-commits

Author: Vitaly Buka
Date: 2022-09-19T10:11:37-07:00
New Revision: 8edce2ff049d2fc635fc20c658daa283661a9958

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

LOG: [test][clangd] Join back -Xclang and -undef

Added: 


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

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/TestTU.cpp 
b/clang-tools-extra/clangd/unittests/TestTU.cpp
index f7d294ca2c26..03f1cd77191d 100644
--- a/clang-tools-extra/clangd/unittests/TestTU.cpp
+++ b/clang-tools-extra/clangd/unittests/TestTU.cpp
@@ -40,12 +40,14 @@ ParseInputs TestTU::inputs(MockFS &FS) const {
   ParseInputs Inputs;
   Inputs.FeatureModules = FeatureModules;
   auto &Argv = Inputs.CompileCommand.CommandLine;
-  Argv = {"clang", "-Xclang"};
+  Argv = {"clang"};
   // In tests, unless explicitly specified otherwise, omit predefined macros
   // (__GNUC__ etc) for a 25% speedup. There are hundreds, and we'd generate,
   // parse, serialize, and re-parse them!
-  if (!PredefineMacros)
+  if (!PredefineMacros) {
+Argv.push_back("-Xclang");
 Argv.push_back("-undef");
+  }
   // FIXME: this shouldn't need to be conditional, but it breaks a
   // GoToDefinition test for some reason (getMacroArgExpandedLocation fails).
   if (!HeaderCode.empty()) {



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


[PATCH] D134127: [ARM] Check target feature support for __builtin_arm_crc*

2022-09-19 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D134127#3798442 , @dmgreen wrote:

> This looks like a subset of D133359 ?

D133359  looks like it is for AArch64 and may 
change the diagnostic in a more aggressive way.
This patch seems to be in a suitable granule to fix just this clang crash 
problem for AArch32...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134127

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


[PATCH] D134055: [clang-doc] Add support for explicitly typed enums

2022-09-19 Thread Brett Wilson via Phabricator via cfe-commits
brettw updated this revision to Diff 461259.
brettw marked an inline comment as done.

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

https://reviews.llvm.org/D134055

Files:
  clang-tools-extra/clang-doc/BitcodeReader.cpp
  clang-tools-extra/clang-doc/BitcodeWriter.cpp
  clang-tools-extra/clang-doc/BitcodeWriter.h
  clang-tools-extra/clang-doc/HTMLGenerator.cpp
  clang-tools-extra/clang-doc/MDGenerator.cpp
  clang-tools-extra/clang-doc/Representation.h
  clang-tools-extra/clang-doc/Serialize.cpp
  clang-tools-extra/clang-doc/YAMLGenerator.cpp
  clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
  clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp

Index: clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/YAMLGeneratorTest.cpp
@@ -256,7 +256,11 @@
   EXPECT_EQ(Expected, Actual.str());
 }
 
-TEST(YAMLGeneratorTest, emitEnumYAML) {
+// Tests the equivalent of:
+// namespace A {
+// enum e { X };
+// }
+TEST(YAMLGeneratorTest, emitSimpleEnumYAML) {
   EnumInfo I;
   I.Name = "e";
   I.Namespace.emplace_back(EmptySID, "A", InfoType::IT_namespace);
@@ -265,7 +269,7 @@
   I.Loc.emplace_back(12, llvm::SmallString<16>{"test.cpp"});
 
   I.Members.emplace_back("X");
-  I.Scoped = true;
+  I.Scoped = false;
 
   auto G = getYAMLGenerator();
   assert(G);
@@ -286,9 +290,42 @@
 Location:
   - LineNumber:  12
 Filename:'test.cpp'
+Members:
+  - Name:'X'
+Value:   '0'
+...
+)raw";
+  EXPECT_EQ(Expected, Actual.str());
+}
+
+// Tests the equivalent of:
+// enum class e : short { X = FOO_BAR + 2 };
+TEST(YAMLGeneratorTest, enumTypedScopedEnumYAML) {
+  EnumInfo I;
+  I.Name = "e";
+
+  I.Members.emplace_back("X", "-9876", "FOO_BAR + 2");
+  I.Scoped = true;
+  I.BaseType = TypeInfo("short");
+
+  auto G = getYAMLGenerator();
+  assert(G);
+  std::string Buffer;
+  llvm::raw_string_ostream Actual(Buffer);
+  auto Err = G->generateDocForInfo(&I, Actual, ClangDocContext());
+  assert(!Err);
+  std::string Expected =
+  R"raw(---
+USR: ''
+Name:'e'
 Scoped:  true
+BaseType:
+  Type:
+Name:'short'
 Members:
-  - 'X'
+  - Name:'X'
+Value:   '-9876'
+Expr:'FOO_BAR + 2'
 ...
 )raw";
   EXPECT_EQ(Expected, Actual.str());
Index: clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
+++ clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
@@ -266,8 +266,8 @@
   EnumInfo E;
   E.Name = "E";
   E.DefLoc = Location(0, llvm::SmallString<16>{"test.cpp"});
-  E.Members.emplace_back("X");
-  E.Members.emplace_back("Y");
+  E.Members.emplace_back("X", "0");
+  E.Members.emplace_back("Y", "1");
   ExpectedNamespaceWithEnum.ChildEnums.emplace_back(std::move(E));
   CheckNamespaceInfo(&ExpectedNamespaceWithEnum, NamespaceWithEnum);
 
@@ -277,8 +277,8 @@
   G.Name = "G";
   G.Scoped = true;
   G.DefLoc = Location(0, llvm::SmallString<16>{"test.cpp"});
-  G.Members.emplace_back("A");
-  G.Members.emplace_back("B");
+  G.Members.emplace_back("A", "0");
+  G.Members.emplace_back("B", "1");
   ExpectedNamespaceWithScopedEnum.ChildEnums.emplace_back(std::move(G));
   CheckNamespaceInfo(&ExpectedNamespaceWithScopedEnum, NamespaceWithScopedEnum);
 }
Index: clang-tools-extra/clang-doc/YAMLGenerator.cpp
===
--- clang-tools-extra/clang-doc/YAMLGenerator.cpp
+++ clang-tools-extra/clang-doc/YAMLGenerator.cpp
@@ -14,6 +14,7 @@
 
 using namespace clang::doc;
 
+// These define YAML traits for decoding the listed values within a vector.
 LLVM_YAML_IS_SEQUENCE_VECTOR(FieldTypeInfo)
 LLVM_YAML_IS_SEQUENCE_VECTOR(MemberTypeInfo)
 LLVM_YAML_IS_SEQUENCE_VECTOR(Reference)
@@ -21,6 +22,7 @@
 LLVM_YAML_IS_SEQUENCE_VECTOR(CommentInfo)
 LLVM_YAML_IS_SEQUENCE_VECTOR(FunctionInfo)
 LLVM_YAML_IS_SEQUENCE_VECTOR(EnumInfo)
+LLVM_YAML_IS_SEQUENCE_VECTOR(EnumValueInfo)
 LLVM_YAML_IS_SEQUENCE_VECTOR(BaseRecordInfo)
 LLVM_YAML_IS_SEQUENCE_VECTOR(std::unique_ptr)
 LLVM_YAML_IS_SEQUENCE_VECTOR(llvm::SmallString<16>)
@@ -226,10 +228,19 @@
   }
 };
 
+template <> struct MappingTraits {
+  static void mapping(IO &IO, EnumValueInfo &I) {
+IO.mapOptional("Name", I.Name);
+IO.mapOptional("Value", I.Value);
+IO.mapOptional("Expr", I.ValueExpr, SmallString<16>());
+  }
+};
+
 template <> struct MappingTraits {
   static void mapping(IO &IO, EnumInfo &I) {
 SymbolInfoMapping(IO, I);
 IO.mapOptional("Scoped", I.Scoped, false);
+IO.mapOptional("BaseType", I.BaseType);
 IO.mapOptional("Members", I.Members);
   }
 };
Index: clang-tools-extra/clang-doc/Serialize.cpp
=

[PATCH] D134055: [clang-doc] Add support for explicitly typed enums

2022-09-19 Thread Brett Wilson via Phabricator via cfe-commits
brettw added inline comments.



Comment at: clang-tools-extra/clang-doc/BitcodeReader.cpp:53
 
+llvm::Error decodeRecord(const Record &R, llvm::APSInt &Field, llvm::StringRef 
Blob) {
+  auto ByteWidth = R[0];

paulkirth wrote:
> brettw wrote:
> > paulkirth wrote:
> > > do you need to do all of this? APSInt already supports to/from string 
> > > methods, as well as converting to/from integers. can you use that here 
> > > and in the writer to avoid some complexity?
> > I don't think converting to an integer is a good idea because people 
> > sometimes use min/max values for enum values and since this could be signed 
> > or unsigned, it gets kind of complicated.
> > 
> > Serializing a number as a string to bitcode also seemed wrong to me.
> > 
> > The simplest thing would be to store the value as a string in the 
> > EnumValueInfo and then always treat this as a string from then on. If you 
> > want it simplified, I think that's the thing to do. But I thought you would 
> > want the numeric value stored in clang-doc's "ast" because some backends 
> > may want to treat this as a number, check its signed/unsignedness, etc. I 
> > happy to change this if you want.
> Those are fair points, and I think I misread/misunderstood a bit of what's 
> going on here.
> 
> As for encoding/decoding integers,  BitcodeWriter already has integer 
> support, so if you need to convert to/from those, it should already work, 
> right?
> 
> Regardless, you may want to look at the bitcode reader/writer in llvm to see 
> how they serialize/deserialize APInt, as their implementation seems a bit 
> more straightforward IMO.
> 
> https://github.com/llvm/llvm-project/blob/9050a59c6678789831b7286b8b68d18b966c4694/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp#L1636
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp#L2520
> https://github.com/llvm/llvm-project/blob/9050a59c6678789831b7286b8b68d18b966c4694/llvm/lib/Bitcode/Reader/BitcodeReader.cpp#L2843
> https://github.com/llvm/llvm-project/blob/9050a59c6678789831b7286b8b68d18b966c4694/llvm/lib/Bitcode/Reader/BitcodeReader.cpp#L2743
I just converted everything to a string which allowed most of this code to be 
deleted. I don't think any theoretical benefit of keeping the APSInt is worth 
the complexity.



Comment at: clang-tools-extra/clang-doc/BitcodeReader.cpp:71
+
+  llvm::SmallVector AsWords;
+  AsWords.resize(WordWidth);

paulkirth wrote:
> You can avoid the resize w/ SmallVector(Size) constructor, right?
This is now deleted.



Comment at: clang-tools-extra/clang-doc/Representation.h:425
+  // constant. This will be empty for implicit enumeration values.
+  std::string ValueExpr;
+};

paulkirth wrote:
> Sorry to nitpick, but SmallString was the correct choice to use in this type. 
> We avoid its use as a return value, because it tends to be brittle, and stops 
> us from assigning into arbitrary sized SmallStrings.  In the struct, it's a 
> reasonable choice, especially if you expect most uses to be small.  for these 
> expressions, I expect most to either be the number itself, or some shift 
> operation, so SmallString<16> was probably more than sufficient.
In the common case there will be will be empty, so std::string actually seems 
more efficient. Also, I personally think the current quantity of SmallString in 
this code is over-optimization.


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

https://reviews.llvm.org/D134055

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


[PATCH] D134180: [clang] Fix a nullptr-access crash in CheckTemplateArgument.

2022-09-19 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 461260.
hokein marked an inline comment as done.
hokein added a comment.

address review comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134180

Files:
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp


Index: clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
@@ -558,3 +558,24 @@
   X<1, 1u>::type y; // expected-error {{no type named 'type' in 
'TypeSuffix::X<1, 1U>'}}
   X<1, 1>::type z; // expected-error {{no type named 'type' in 
'TypeSuffix::X<1, 1>'}}
 }
+
+namespace no_crash {
+template 
+class Base {
+public:
+  template  class EntryPointSpec {};
+  template 
+  using EntryPoint = EntryPointSpec;
+};
+
+class Derived : Base{
+  template  class Spec {};
+
+  void Invalid(Undefined) const; // expected-error {{unknown type name 
'Undefined'}}
+  void crash() {
+return Spec{
+EntryPoint<&Invalid>()
+};
+  }
+};
+} // no_crash
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -6949,7 +6949,10 @@
  // along with the other associated constraints after
  // checking the template argument list.
  /*IgnoreConstraints=*/true);
-  if (Result != TDK_Success && Result != TDK_AlreadyDiagnosed) {
+  if (Result == TDK_AlreadyDiagnosed) {
+if (ParamType.isNull())
+  return ExprError();
+  } else if (Result != TDK_Success) {
 Diag(Arg->getExprLoc(),
  diag::err_non_type_template_parm_type_deduction_failure)
 << Param->getDeclName() << Param->getType() << Arg->getType()


Index: clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
@@ -558,3 +558,24 @@
   X<1, 1u>::type y; // expected-error {{no type named 'type' in 'TypeSuffix::X<1, 1U>'}}
   X<1, 1>::type z; // expected-error {{no type named 'type' in 'TypeSuffix::X<1, 1>'}}
 }
+
+namespace no_crash {
+template 
+class Base {
+public:
+  template  class EntryPointSpec {};
+  template 
+  using EntryPoint = EntryPointSpec;
+};
+
+class Derived : Base{
+  template  class Spec {};
+
+  void Invalid(Undefined) const; // expected-error {{unknown type name 'Undefined'}}
+  void crash() {
+return Spec{
+EntryPoint<&Invalid>()
+};
+  }
+};
+} // no_crash
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -6949,7 +6949,10 @@
  // along with the other associated constraints after
  // checking the template argument list.
  /*IgnoreConstraints=*/true);
-  if (Result != TDK_Success && Result != TDK_AlreadyDiagnosed) {
+  if (Result == TDK_AlreadyDiagnosed) {
+if (ParamType.isNull())
+  return ExprError();
+  } else if (Result != TDK_Success) {
 Diag(Arg->getExprLoc(),
  diag::err_non_type_template_parm_type_deduction_failure)
 << Param->getDeclName() << Param->getType() << Arg->getType()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D134180: [clang] Fix a nullptr-access crash in CheckTemplateArgument.

2022-09-19 Thread Haojian Wu via Phabricator via cfe-commits
hokein added inline comments.



Comment at: clang/lib/Sema/SemaTemplate.cpp:6960
+if (ParamType.isNull())
+  return ExprError();
 // CheckNonTypeTemplateParameterType will produce a diagnostic if there's

adamcz wrote:
> So this can only happen when Result is TDK_AlreadyDiagnosed above, right? In 
> that case, I would handle such case explicitly in the code above, like:
> if (Result == TDK_AlreadyDiagnosed) return ExprError();
> else if (Result != TDK_Success) { ... }
> Seems like it would be more readable. 
> 
> However, I am definitely not opposed to keeping this check here as well, in 
> case there are other ways to get into this situation.
right. I think either of them works, switched to your version. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134180

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


[PATCH] D134180: [clang] Fix a nullptr-access crash in CheckTemplateArgument.

2022-09-19 Thread Haojian Wu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe782d9a4a49c: [clang] Fix a nullptr-access crash in 
CheckTemplateArgument. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134180

Files:
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp


Index: clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
@@ -558,3 +558,24 @@
   X<1, 1u>::type y; // expected-error {{no type named 'type' in 
'TypeSuffix::X<1, 1U>'}}
   X<1, 1>::type z; // expected-error {{no type named 'type' in 
'TypeSuffix::X<1, 1>'}}
 }
+
+namespace no_crash {
+template 
+class Base {
+public:
+  template  class EntryPointSpec {};
+  template 
+  using EntryPoint = EntryPointSpec;
+};
+
+class Derived : Base{
+  template  class Spec {};
+
+  void Invalid(Undefined) const; // expected-error {{unknown type name 
'Undefined'}}
+  void crash() {
+return Spec{
+EntryPoint<&Invalid>()
+};
+  }
+};
+} // no_crash
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -6949,7 +6949,10 @@
  // along with the other associated constraints after
  // checking the template argument list.
  /*IgnoreConstraints=*/true);
-  if (Result != TDK_Success && Result != TDK_AlreadyDiagnosed) {
+  if (Result == TDK_AlreadyDiagnosed) {
+if (ParamType.isNull())
+  return ExprError();
+  } else if (Result != TDK_Success) {
 Diag(Arg->getExprLoc(),
  diag::err_non_type_template_parm_type_deduction_failure)
 << Param->getDeclName() << Param->getType() << Arg->getType()


Index: clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
@@ -558,3 +558,24 @@
   X<1, 1u>::type y; // expected-error {{no type named 'type' in 'TypeSuffix::X<1, 1U>'}}
   X<1, 1>::type z; // expected-error {{no type named 'type' in 'TypeSuffix::X<1, 1>'}}
 }
+
+namespace no_crash {
+template 
+class Base {
+public:
+  template  class EntryPointSpec {};
+  template 
+  using EntryPoint = EntryPointSpec;
+};
+
+class Derived : Base{
+  template  class Spec {};
+
+  void Invalid(Undefined) const; // expected-error {{unknown type name 'Undefined'}}
+  void crash() {
+return Spec{
+EntryPoint<&Invalid>()
+};
+  }
+};
+} // no_crash
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -6949,7 +6949,10 @@
  // along with the other associated constraints after
  // checking the template argument list.
  /*IgnoreConstraints=*/true);
-  if (Result != TDK_Success && Result != TDK_AlreadyDiagnosed) {
+  if (Result == TDK_AlreadyDiagnosed) {
+if (ParamType.isNull())
+  return ExprError();
+  } else if (Result != TDK_Success) {
 Diag(Arg->getExprLoc(),
  diag::err_non_type_template_parm_type_deduction_failure)
 << Param->getDeclName() << Param->getType() << Arg->getType()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] e782d9a - [clang] Fix a nullptr-access crash in CheckTemplateArgument.

2022-09-19 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2022-09-19T19:18:50+02:00
New Revision: e782d9a4a49c8aaf65bea4209cb6a8e7739526ac

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

LOG: [clang] Fix a nullptr-access crash in CheckTemplateArgument.

It is possible that we can pass a null ParamType to
CheckNonTypeTemplateParameter -- the ParamType var can be reset to a null
type on Line 6940, and the followed bailout if is not entered.

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

Added: 


Modified: 
clang/lib/Sema/SemaTemplate.cpp
clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index adca91b0ae63e..e0f913e395771 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -6949,7 +6949,10 @@ ExprResult 
Sema::CheckTemplateArgument(NonTypeTemplateParmDecl *Param,
  // along with the other associated constraints after
  // checking the template argument list.
  /*IgnoreConstraints=*/true);
-  if (Result != TDK_Success && Result != TDK_AlreadyDiagnosed) {
+  if (Result == TDK_AlreadyDiagnosed) {
+if (ParamType.isNull())
+  return ExprError();
+  } else if (Result != TDK_Success) {
 Diag(Arg->getExprLoc(),
  diag::err_non_type_template_parm_type_deduction_failure)
 << Param->getDeclName() << Param->getType() << Arg->getType()

diff  --git a/clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp 
b/clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
index 8c290cb69772d..24c486cb35ad3 100644
--- a/clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
+++ b/clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
@@ -558,3 +558,24 @@ namespace TypeSuffix {
   X<1, 1u>::type y; // expected-error {{no type named 'type' in 
'TypeSuffix::X<1, 1U>'}}
   X<1, 1>::type z; // expected-error {{no type named 'type' in 
'TypeSuffix::X<1, 1>'}}
 }
+
+namespace no_crash {
+template 
+class Base {
+public:
+  template  class EntryPointSpec {};
+  template 
+  using EntryPoint = EntryPointSpec;
+};
+
+class Derived : Base{
+  template  class Spec {};
+
+  void Invalid(Undefined) const; // expected-error {{unknown type name 
'Undefined'}}
+  void crash() {
+return Spec{
+EntryPoint<&Invalid>()
+};
+  }
+};
+} // no_crash



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


[PATCH] D134055: [clang-doc] Add support for explicitly typed enums

2022-09-19 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth accepted this revision.
paulkirth added a comment.
This revision is now accepted and ready to land.

LGTM.


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

https://reviews.llvm.org/D134055

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


[clang] 7538b36 - [clang][dataflow] Replace usage of deprecated functions with the optional check

2022-09-19 Thread Wei Yi Tee via cfe-commits

Author: Wei Yi Tee
Date: 2022-09-19T17:33:25Z
New Revision: 7538b3604519b03d32221cdcc346cc1c181b50fb

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

LOG: [clang][dataflow] Replace usage of deprecated functions with the optional 
check

- Update `transfer` and `diagnose` to take `const CFGElement *` as input in 
`Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel`.
- Update 
`clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp` 
accordingly.
- Rename `runDataflowAnalysisOnCFG` to `runDataflowAnalysis` and remove the 
deprecated `runDataflowAnalysis` (this was only used by the now updated 
optional check).

Reviewed By: gribozavr2, sgatev

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h

clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h
clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
index 5ee1a0126b232..b2f6b9ed62843 100644
--- a/clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
@@ -59,12 +59,11 @@ analyzeFunction(const FunctionDecl &FuncDecl, ASTContext 
&ASTCtx) {
   BlockToOutputState = dataflow::runDataflowAnalysis(
   *Context, Analysis, Env,
   [&ASTCtx, &Diagnoser, &Diagnostics](
-  const CFGStmt &Stmt,
+  const CFGElement &Elt,
   const 
DataflowAnalysisState
   &State) mutable {
-auto StmtDiagnostics =
-Diagnoser.diagnose(ASTCtx, Stmt.getStmt(), State.Env);
-llvm::move(StmtDiagnostics, std::back_inserter(Diagnostics));
+auto EltDiagnostics = Diagnoser.diagnose(ASTCtx, &Elt, State.Env);
+llvm::move(EltDiagnostics, std::back_inserter(Diagnostics));
   });
   if (!BlockToOutputState)
 return llvm::None;

diff  --git a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
index 4e084d57ba011..098c13cf4e35a 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -136,9 +136,6 @@ template  struct DataflowAnalysisState {
   Environment Env;
 };
 
-// FIXME: Rename to `runDataflowAnalysis` after usages of the overload that
-// applies to `CFGStmt` have been replaced.
-//
 /// Performs dataflow analysis and returns a mapping from basic block IDs to
 /// dataflow analysis states that model the respective basic blocks. The
 /// returned vector, if any, will have the same size as the number of CFG
@@ -149,7 +146,7 @@ template  struct DataflowAnalysisState {
 template 
 llvm::Expected>>>
-runDataflowAnalysisOnCFG(
+runDataflowAnalysis(
 const ControlFlowContext &CFCtx, AnalysisT &Analysis,
 const Environment &InitEnv,
 std::function
-llvm::Expected>>>
-runDataflowAnalysis(
-const ControlFlowContext &CFCtx, AnalysisT &Analysis,
-const Environment &InitEnv,
-std::function &)>
-PostVisitStmt = nullptr) {
-  std::function &)>
-  PostVisitCFG = nullptr;
-  if (PostVisitStmt) {
-PostVisitCFG =
-[&PostVisitStmt](
-const CFGElement &Element,
-const DataflowAnalysisState &State) {
-  if (auto Stmt = Element.getAs()) {
-PostVisitStmt(*Stmt, State);
-  }
-};
-  }
-  return runDataflowAnalysisOnCFG(CFCtx, Analysis, InitEnv, PostVisitCFG);
-}
-
 /// Abstract base class for dataflow "models": reusable analysis components 
that
 /// model a particular aspect of program semantics in the `Environment`. For
 /// example, a model may capture a type and its related functions.

diff  --git 
a/clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h
 
b/clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h
index 25054deaf8afc..66aabb531a213 100644
--- 
a/clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h
+++ 
b/clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h
@@ -15,10 +15,10 @@
 #define CLANG_ANALYSIS_FLOWSENSITIVE_MODELS_UNCHECKEDOPTIONALACCESSMODEL_H
 
 #include "clang/AST/ASTContext.h"
-#include "clang/AST/Stmt.h"
+#include "clang/Analysis/CFG.h"
+#include "clang/Analysis/FlowS

[PATCH] D133930: [clang][dataflow] Replace usage of deprecated functions with the optional check

2022-09-19 Thread weiyi via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7538b3604519: [clang][dataflow] Replace usage of deprecated 
functions with the optional check (authored by wyt).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133930

Files:
  clang-tools-extra/clang-tidy/bugprone/UncheckedOptionalAccessCheck.cpp
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
  
clang/include/clang/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.h
  clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
  clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/UncheckedOptionalAccessModelTest.cpp
@@ -14,10 +14,8 @@
 #include "clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Tooling/Tooling.h"
-#include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/STLExtras.h"
-#include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/Error.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -1248,13 +1246,9 @@
  Diagnoser = UncheckedOptionalAccessDiagnoser(Options)](
 ASTContext &Ctx, const CFGElement &Elt,
 const TypeErasedDataflowAnalysisState &State) mutable {
-  auto Stmt = Elt.getAs();
-  if (!Stmt) {
-return;
-  }
-  auto StmtDiagnostics =
-  Diagnoser.diagnose(Ctx, Stmt->getStmt(), State.Env);
-  llvm::move(StmtDiagnostics, std::back_inserter(Diagnostics));
+  auto EltDiagnostics =
+  Diagnoser.diagnose(Ctx, &Elt, State.Env);
+  llvm::move(EltDiagnostics, std::back_inserter(Diagnostics));
 })
 .withASTBuildArgs(
 {"-fsyntax-only", "-std=c++17", "-Wno-undefined-inline"})
Index: clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
===
--- clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
+++ clang/lib/Analysis/FlowSensitive/Models/UncheckedOptionalAccessModel.cpp
@@ -18,8 +18,9 @@
 #include "clang/AST/ExprCXX.h"
 #include "clang/AST/Stmt.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/CFG.h"
+#include "clang/Analysis/FlowSensitive/CFGMatchSwitch.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
-#include "clang/Analysis/FlowSensitive/MatchSwitch.h"
 #include "clang/Analysis/FlowSensitive/NoopLattice.h"
 #include "clang/Analysis/FlowSensitive/Value.h"
 #include "clang/Basic/SourceLocation.h"
@@ -559,41 +560,42 @@
   // lot of duplicated work (e.g. string comparisons), consider providing APIs
   // that avoid it through memoization.
   auto IgnorableOptional = ignorableOptional(Options);
-  return MatchSwitchBuilder()
+  return CFGMatchSwitchBuilder()
   // Attach a symbolic "has_value" state to optional values that we see for
   // the first time.
-  .CaseOf(
+  .CaseOfCFGStmt(
   expr(anyOf(declRefExpr(), memberExpr()), hasOptionalType()),
   initializeOptionalReference)
 
   // make_optional
-  .CaseOf(isMakeOptionalCall(), transferMakeOptionalCall)
+  .CaseOfCFGStmt(isMakeOptionalCall(), transferMakeOptionalCall)
 
   // optional::optional
-  .CaseOf(
+  .CaseOfCFGStmt(
   isOptionalInPlaceConstructor(),
   [](const CXXConstructExpr *E, const MatchFinder::MatchResult &,
  LatticeTransferState &State) {
 assignOptionalValue(*E, State, State.Env.getBoolLiteralValue(true));
   })
-  .CaseOf(
+  .CaseOfCFGStmt(
   isOptionalNulloptConstructor(),
   [](const CXXConstructExpr *E, const MatchFinder::MatchResult &,
  LatticeTransferState &State) {
 assignOptionalValue(*E, State,
 State.Env.getBoolLiteralValue(false));
   })
-  .CaseOf(isOptionalValueOrConversionConstructor(),
-transferValueOrConversionConstructor)
+  .CaseOfCFGStmt(isOptionalValueOrConversionConstructor(),
+   transferValueOrConversionConstructor)
 
   // optional::operator=
-  .CaseOf(isOptionalValueOrConversionAssignment(),
-   transferValueOrConversionAssignment)
-  .CaseOf(isOptionalNulloptAssignment(),
-   transferNulloptAssignment)
+  .CaseOfCFGStmt(
+  isOpti

[PATCH] D134189: [CUDA][HIP] Fix new driver crashing when using -save-temps in RDC-mode

2022-09-19 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:4391
 DDep.add(*PackagerAction, *C.getSingleOffloadToolChain(),
- nullptr, Action::OFK_None);
+ nullptr, C.getActiveOffloadKinds());
   }

`getActiveOffloadKinds` returns a mask of offload kinds, yet we cast it to 
`OffloadKind` in `DeviceDependences::add` above. This mixing of OffloadKind and 
sets of them looks questionable to me.

If we are relying on passing sets of `OffloadKind`now, then we should make it 
clear in the code that it is the intent, including a more detailed description 
that `DeviceOffloadKinds` is a list of `OffloadKind` sets, so whoever iterates 
over elements does not attempt to compare its elements with `OffloadKind` 
values. I think it would be helpful to change `DeviceOffloadKinds` element type 
to a new class with a helper method `hasOffloadKind(OffloadKind)` to avoid 
accidental comparison of a mask with enum value.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134189

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


[PATCH] D133993: [HLSL] Remove global ctor/dtor variable for non-lib profile.

2022-09-19 Thread Xiang Li via Phabricator via cfe-commits
python3kgae updated this revision to Diff 461271.
python3kgae added a comment.
Herald added a reviewer: aaron.ballman.

Add test for dtor in lib.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133993

Files:
  clang/lib/CodeGen/CGHLSLRuntime.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGenHLSL/GlobalConstructorFunction.hlsl
  clang/test/CodeGenHLSL/GlobalConstructorLib.hlsl
  clang/test/CodeGenHLSL/GlobalConstructors.hlsl
  clang/test/CodeGenHLSL/GlobalDestructors.hlsl
  clang/test/CodeGenHLSL/GlobalDestructorsLib.hlsl

Index: clang/test/CodeGenHLSL/GlobalDestructorsLib.hlsl
===
--- clang/test/CodeGenHLSL/GlobalDestructorsLib.hlsl
+++ clang/test/CodeGenHLSL/GlobalDestructorsLib.hlsl
@@ -1,4 +1,7 @@
-// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.0-compute -std=hlsl202x -S -emit-llvm -disable-llvm-passes %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -std=hlsl202x -S -emit-llvm -disable-llvm-passes %s -o - | FileCheck %s
+
+// Make sure global variable for dtors exist for lib profile.
+// CHECK:@llvm.global_dtors
 
 struct Tail {
   Tail() {
@@ -39,9 +42,10 @@
   Wag();
 }
 
+
 //CHECK:  define void @main()
 //CHECK-NEXT: entry:
-//CHECK-NEXT:   call void @_GLOBAL__sub_I_GlobalDestructors.hlsl()
+//CHECK-NEXT:   call void @_GLOBAL__sub_I_GlobalDestructorsLib.hlsl()
 //CHECK-NEXT:   %0 = call i32 @llvm.dx.flattened.thread.id.in.group()
 //CHECK-NEXT:   call void @"?main@@YAXI@Z"(i32 %0)
 //CHECK-NEXT:   call void @_GLOBAL__D_a()
Index: clang/test/CodeGenHLSL/GlobalDestructors.hlsl
===
--- clang/test/CodeGenHLSL/GlobalDestructors.hlsl
+++ clang/test/CodeGenHLSL/GlobalDestructors.hlsl
@@ -39,6 +39,9 @@
   Wag();
 }
 
+// Make sure global variable for ctors/dtors removed.
+// CHECK-NOT:@llvm.global_ctors
+// CHECK-NOT:@llvm.global_dtors
 //CHECK:  define void @main()
 //CHECK-NEXT: entry:
 //CHECK-NEXT:   call void @_GLOBAL__sub_I_GlobalDestructors.hlsl()
Index: clang/test/CodeGenHLSL/GlobalConstructors.hlsl
===
--- clang/test/CodeGenHLSL/GlobalConstructors.hlsl
+++ clang/test/CodeGenHLSL/GlobalConstructors.hlsl
@@ -5,6 +5,9 @@
 [numthreads(1,1,1)]
 void main(unsigned GI : SV_GroupIndex) {}
 
+// Make sure global variable for ctors/dtors removed.
+// CHECK-NOT:@llvm.global_ctors
+// CHECK-NOT:@llvm.global_dtors
 //CHECK:  define void @main()
 //CHECK-NEXT: entry:
 //CHECK-NEXT:   call void @_GLOBAL__sub_I_GlobalConstructors.hlsl()
Index: clang/test/CodeGenHLSL/GlobalConstructorLib.hlsl
===
--- clang/test/CodeGenHLSL/GlobalConstructorLib.hlsl
+++ clang/test/CodeGenHLSL/GlobalConstructorLib.hlsl
@@ -1,5 +1,8 @@
 // RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -S -emit-llvm -disable-llvm-passes %s -o - | FileCheck %s
 
+// Make sure global variable for ctors exist for lib profile.
+// CHECK:@llvm.global_ctors
+
 RWBuffer Buffer;
 
 [shader("compute")]
Index: clang/test/CodeGenHLSL/GlobalConstructorFunction.hlsl
===
--- clang/test/CodeGenHLSL/GlobalConstructorFunction.hlsl
+++ clang/test/CodeGenHLSL/GlobalConstructorFunction.hlsl
@@ -17,6 +17,10 @@
 [numthreads(1,1,1)]
 void main(unsigned GI : SV_GroupIndex) {}
 
+// Make sure global variable for ctors/dtors removed.
+// CHECK-NOT:@llvm.global_ctors
+// CHECK-NOT:@llvm.global_dtors
+
 //CHECK: define void @main()
 //CHECK-NEXT: entry:
 //CHECK-NEXT:   call void @"?call_me_first@@YAXXZ"()
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -6895,7 +6895,10 @@
 static void handleHLSLSVGroupIndexAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
   using llvm::Triple;
   Triple Target = S.Context.getTargetInfo().getTriple();
-  if (Target.getEnvironment() != Triple::Compute) {
+  if (Target.getEnvironment() != Triple::Compute &&
+  Target.getEnvironment() != Triple::Library) {
+// FIXME: it is OK for a compute shader entry and pixel shader entry live in
+// same HLSL file.
 uint32_t Pipeline =
 (uint32_t)S.Context.getTargetInfo().getTriple().getEnvironment() -
 (uint32_t)llvm::Triple::Pixel;
Index: clang/lib/CodeGen/CGHLSLRuntime.cpp
===
--- clang/lib/CodeGen/CGHLSLRuntime.cpp
+++ clang/lib/CodeGen/CGHLSLRuntime.cpp
@@ -202,4 +202,14 @@
 for (auto *Fn : DtorFns)
   B.CreateCall(FunctionCallee(Fn));
   }
+
+  // No need to keep global ctors/dtors for non-lib profile after call to
+  // ctors/dtors added for entry.
+  Triple T(M.getTargetTriple());
+  if (T.getEnvironment() != T

[PATCH] D133890: [CMake] Do these replacements to make use of D132608

2022-09-19 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd added a comment.

I don't see anything wrong with this change per se, but I'm conflicted on the 
name of the variable.  These are not standard variables but are encroaching on 
the CMake namespace.  What happens if upstream decides to use these names?  I 
think that we should keep the names in the `LLVM_` namespace.  However, I 
realize that the variable itself is not being touched here and this is a 
mechanical replacement.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133890

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


[clang] cf94c52 - [clang][dataflow] Replace `transfer(const Stmt *, ...)` with `transfer(const CFGElement *, ...)` in `clang/Analysis/FlowSensitive`.

2022-09-19 Thread Wei Yi Tee via cfe-commits

Author: Wei Yi Tee
Date: 2022-09-19T18:06:57Z
New Revision: cf94c52e35f2daf4e4caaeb93648f4b5413b557a

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

LOG: [clang][dataflow] Replace `transfer(const Stmt *, ...)` with 
`transfer(const CFGElement *, ...)` in `clang/Analysis/FlowSensitive`.

Reviewed By: gribozavr2, sgatev

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

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/NoopAnalysis.h
clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/NoopAnalysis.h 
b/clang/include/clang/Analysis/FlowSensitive/NoopAnalysis.h
index 4f05f5f4554bb..bf27ec3a58ddb 100644
--- a/clang/include/clang/Analysis/FlowSensitive/NoopAnalysis.h
+++ b/clang/include/clang/Analysis/FlowSensitive/NoopAnalysis.h
@@ -14,7 +14,7 @@
 #define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_NOOPANALYSIS_H
 
 #include "clang/AST/ASTContext.h"
-#include "clang/AST/Stmt.h"
+#include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/DataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/NoopLattice.h"
@@ -38,7 +38,7 @@ class NoopAnalysis : public DataflowAnalysis {
 
   static NoopLattice initialElement() { return {}; }
 
-  void transfer(const Stmt *S, NoopLattice &E, Environment &Env) {}
+  void transfer(const CFGElement *E, NoopLattice &L, Environment &Env) {}
 };
 
 } // namespace dataflow

diff  --git a/clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
index ea171f7c1fbd9..574366963bd67 100644
--- a/clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
@@ -11,6 +11,7 @@
 #include "TestingSupport.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/NoopLattice.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/ArrayRef.h"
@@ -117,8 +118,10 @@ class ModelAdaptorAnalysis
 
   static NoopLattice initialElement() { return NoopLattice(); }
 
-  void transfer(const Stmt *S, NoopLattice &, Environment &Env) {
-M.transfer(S, Env);
+  void transfer(const CFGElement *E, NoopLattice &, Environment &Env) {
+if (auto S = E->getAs()) {
+  M.transfer(S->getStmt(), Env);
+}
   }
 
 private:

diff  --git 
a/clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
index d2e774db5a3f4..39a1e1dd0859f 100644
--- a/clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
@@ -19,6 +19,7 @@
 #include "clang/AST/Stmt.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/DataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
@@ -132,8 +133,12 @@ class ConstantPropagationAnalysis
 return ConstantPropagationLattice::bottom();
   }
 
-  void transfer(const Stmt *S, ConstantPropagationLattice &Vars,
+  void transfer(const CFGElement *E, ConstantPropagationLattice &Vars,
 Environment &Env) {
+auto CS = E->getAs();
+if (!CS)
+  return;
+auto S = CS->getStmt();
 auto matcher =
 stmt(anyOf(declStmt(hasSingleDecl(
varDecl(decl().bind(kVar), hasType(isInteger()),

diff  --git 
a/clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
index 67c86f130c977..60b7860917899 100644
--- 
a/clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
+++ 
b/clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
@@ -19,10 +19,10 @@
 #include "clang/AST/Stmt.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/DataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
-#include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/None.h"
 #in

[PATCH] D133931: [clang][dataflow] Replace `transfer(const Stmt *, ...)` with `transfer(const CFGElement *, ...)` in `clang/Analysis/FlowSensitive`.

2022-09-19 Thread weiyi 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 rGcf94c52e35f2: [clang][dataflow] Replace `transfer(const Stmt 
*, ...)` with `transfer(const… (authored by wyt).

Changed prior to commit:
  https://reviews.llvm.org/D133931?vs=460350&id=461278#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133931

Files:
  clang/include/clang/Analysis/FlowSensitive/NoopAnalysis.h
  clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
  clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
  clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -111,7 +111,7 @@
 
   static NonConvergingLattice initialElement() { return {0}; }
 
-  void transfer(const Stmt *S, NonConvergingLattice &E, Environment &Env) {
+  void transfer(const CFGElement *, NonConvergingLattice &E, Environment &) {
 ++E.State;
   }
 };
@@ -162,7 +162,11 @@
 
   static FunctionCallLattice initialElement() { return {}; }
 
-  void transfer(const Stmt *S, FunctionCallLattice &E, Environment &Env) {
+  void transfer(const CFGElement *Elt, FunctionCallLattice &E, Environment &) {
+auto CS = Elt->getAs();
+if (!CS)
+  return;
+auto S = CS->getStmt();
 if (auto *C = dyn_cast(S)) {
   if (auto *F = dyn_cast(C->getCalleeDecl())) {
 E.CalledFunctions.insert(F->getNameInfo().getAsString());
@@ -314,7 +318,11 @@
 
   static NoopLattice initialElement() { return {}; }
 
-  void transfer(const Stmt *S, NoopLattice &, Environment &Env) {
+  void transfer(const CFGElement *Elt, NoopLattice &, Environment &Env) {
+auto CS = Elt->getAs();
+if (!CS)
+  return;
+auto S = CS->getStmt();
 auto SpecialBoolRecordDecl = recordDecl(hasName("SpecialBool"));
 auto HasSpecialBoolType = hasType(SpecialBoolRecordDecl);
 
@@ -466,7 +474,11 @@
 
   static NoopLattice initialElement() { return {}; }
 
-  void transfer(const Stmt *S, NoopLattice &, Environment &Env) {
+  void transfer(const CFGElement *Elt, NoopLattice &, Environment &Env) {
+auto CS = Elt->getAs();
+if (!CS)
+  return;
+auto S = CS->getStmt();
 auto OptionalIntRecordDecl = recordDecl(hasName("OptionalInt"));
 auto HasOptionalIntType = hasType(OptionalIntRecordDecl);
 
Index: clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/SingleVarConstantPropagationTest.cpp
@@ -19,10 +19,10 @@
 #include "clang/AST/Stmt.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/DataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
-#include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/None.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/StringRef.h"
@@ -123,8 +123,12 @@
 return ConstantPropagationLattice::bottom();
   }
 
-  void transfer(const Stmt *S, ConstantPropagationLattice &Element,
+  void transfer(const CFGElement *E, ConstantPropagationLattice &Element,
 Environment &Env) {
+auto CS = E->getAs();
+if (!CS)
+  return;
+auto S = CS->getStmt();
 auto matcher = stmt(
 anyOf(declStmt(hasSingleDecl(varDecl(hasType(isInteger()),
  hasInitializer(expr().bind(kInit)))
Index: clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/MultiVarConstantPropagationTest.cpp
@@ -19,6 +19,7 @@
 #include "clang/AST/Stmt.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/DataflowAnalysis.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/DataflowLattice.h"
@@ -132,8 +133,12 @@
 return ConstantPropagationLattice::bottom();
   }
 
-  void transfer(const Stmt *S, ConstantPropagationLattice &Vars,
+  void transfer(const CFGElement *E, ConstantPropagationLattice &Vars,

[PATCH] D134189: [CUDA][HIP] Fix new driver crashing when using -save-temps in RDC-mode

2022-09-19 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 updated this revision to Diff 461286.
jhuber6 added a comment.

Mixing the concept of the mask passing via an `unsigned` and a single enum 
value was incorrect. Add a new interface that accepts a mask and adds all 
active values instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134189

Files:
  clang/include/clang/Driver/Action.h
  clang/lib/Driver/Action.cpp
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/amdgpu-openmp-toolchain.c
  clang/test/Driver/cuda-bindings.cu
  clang/test/Driver/cuda-phases.cu
  clang/test/Driver/openmp-offload-gpu.c
  clang/test/Driver/openmp-offload.c

Index: clang/test/Driver/openmp-offload.c
===
--- clang/test/Driver/openmp-offload.c
+++ clang/test/Driver/openmp-offload.c
@@ -110,8 +110,8 @@
 // CHK-PHASES-NEXT: 7: backend, {6}, assembler, (device-openmp)
 // CHK-PHASES-NEXT: 8: assembler, {7}, object, (device-openmp)
 // CHK-PHASES-NEXT: 9: offload, "device-openmp (powerpc64-ibm-linux-gnu)" {8}, object
-// CHK-PHASES-NEXT: 10: clang-offload-packager, {9}, image
-// CHK-PHASES-NEXT: 11: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {2}, " (powerpc64-ibm-linux-gnu)" {10}, ir
+// CHK-PHASES-NEXT: 10: clang-offload-packager, {9}, image, (device-openmp)
+// CHK-PHASES-NEXT: 11: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {2}, "device-openmp (powerpc64-ibm-linux-gnu)" {10}, ir
 // CHK-PHASES-NEXT: 12: backend, {11}, assembler, (host-openmp)
 // CHK-PHASES-NEXT: 13: assembler, {12}, object, (host-openmp)
 // CHK-PHASES-NEXT: 14: clang-linker-wrapper, {13}, image, (host-openmp)
@@ -139,8 +139,8 @@
 // CHK-PHASES-FILES-NEXT: 15: backend, {14}, assembler, (device-openmp)
 // CHK-PHASES-FILES-NEXT: 16: assembler, {15}, object, (device-openmp)
 // CHK-PHASES-FILES-NEXT: 17: offload, "device-openmp (powerpc64-ibm-linux-gnu)" {16}, object
-// CHK-PHASES-FILES-NEXT: 18: clang-offload-packager, {10, 17}, image
-// CHK-PHASES-FILES-NEXT: 19: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {3}, " (powerpc64-ibm-linux-gnu)" {18}, ir
+// CHK-PHASES-FILES-NEXT: 18: clang-offload-packager, {10, 17}, image, (device-openmp)
+// CHK-PHASES-FILES-NEXT: 19: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {3}, "device-openmp (powerpc64-ibm-linux-gnu)" {18}, ir
 // CHK-PHASES-FILES-NEXT: 20: backend, {19}, assembler, (host-openmp)
 // CHK-PHASES-FILES-NEXT: 21: assembler, {20}, object, (host-openmp)
 // CHK-PHASES-FILES-NEXT: 22: input, "[[INPUT]]", c, (host-openmp)
@@ -160,8 +160,8 @@
 // CHK-PHASES-FILES-NEXT: 36: backend, {35}, assembler, (device-openmp)
 // CHK-PHASES-FILES-NEXT: 37: assembler, {36}, object, (device-openmp)
 // CHK-PHASES-FILES-NEXT: 38: offload, "device-openmp (powerpc64-ibm-linux-gnu)" {37}, object
-// CHK-PHASES-FILES-NEXT: 39: clang-offload-packager, {31, 38}, image
-// CHK-PHASES-FILES-NEXT: 40: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {24}, " (powerpc64-ibm-linux-gnu)" {39}, ir
+// CHK-PHASES-FILES-NEXT: 39: clang-offload-packager, {31, 38}, image, (device-openmp)
+// CHK-PHASES-FILES-NEXT: 40: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {24}, "device-openmp (powerpc64-ibm-linux-gnu)" {39}, ir
 // CHK-PHASES-FILES-NEXT: 41: backend, {40}, assembler, (host-openmp)
 // CHK-PHASES-FILES-NEXT: 42: assembler, {41}, object, (host-openmp)
 // CHK-PHASES-FILES-NEXT: 43: clang-linker-wrapper, {0, 21, 42}, image, (host-openmp)
Index: clang/test/Driver/openmp-offload-gpu.c
===
--- clang/test/Driver/openmp-offload-gpu.c
+++ clang/test/Driver/openmp-offload-gpu.c
@@ -258,7 +258,7 @@
 // CHECK-PHASES: 8: assembler, {7}, object, (device-openmp)
 // CHECK-PHASES: 9: offload, "device-openmp (nvptx64-nvidia-cuda)" {8}, object
 // CHECK-PHASES: 10: clang-offload-packager, {9}, image
-// CHECK-PHASES: 11: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, " (x86_64-unknown-linux-gnu)" {10}, ir
+// CHECK-PHASES: 11: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (x86_64-unknown-linux-gnu)" {10}, ir
 // CHECK-PHASES: 12: backend, {11}, assembler, (host-openmp)
 // CHECK-PHASES: 13: assembler, {12}, object, (host-openmp)
 // CHECK-PHASES: 14: clang-linker-wrapper, {13}, image, (host-openmp)
Index: clang/test/Driver/cuda-phases.cu
===
--- clang/test/Driver/cuda-phases.cu
+++ clang/test/Driver/cuda-phases.cu
@@ -238,8 +238,8 @@
 // NEW-DRIVER-RDC-NEXT: 12: backend, {11}, assembler, (device-cuda, sm_70)
 // NEW-DRIVER-RDC-NEXT: 13: assembler, {12}, object, (device-cuda, sm_70)
 // NEW-DRIVER-RDC-NEXT: 14: offload, "device-cuda (nvptx64-nvidia-cuda:sm_70)" {13}, object
-// NEW-DRIVER-RDC-NEXT: 15: clang-offload-packager, {8, 14}, image
-// NEW-DRIVER-RDC-NEXT: 16: offload, " (powerpc64le-ibm-linux-gnu)" {2}, " (powerpc64le-ibm-linux-gnu)" {15}, ir
+// NEW-DRIVER-RDC

[PATCH] D134189: [CUDA][HIP] Fix new driver crashing when using -save-temps in RDC-mode

2022-09-19 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 marked an inline comment as done.
jhuber6 added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:4391
 DDep.add(*PackagerAction, *C.getSingleOffloadToolChain(),
- nullptr, Action::OFK_None);
+ nullptr, C.getActiveOffloadKinds());
   }

tra wrote:
> `getActiveOffloadKinds` returns a mask of offload kinds, yet we cast it to 
> `OffloadKind` in `DeviceDependences::add` above. This mixing of OffloadKind 
> and sets of them looks questionable to me.
> 
> If we are relying on passing sets of `OffloadKind`now, then we should make it 
> clear in the code that it is the intent, including a more detailed 
> description that `DeviceOffloadKinds` is a list of `OffloadKind` sets, so 
> whoever iterates over elements does not attempt to compare its elements with 
> `OffloadKind` values. I think it would be helpful to change 
> `DeviceOffloadKinds` element type to a new class with a helper method 
> `hasOffloadKind(OffloadKind)` to avoid accidental comparison of a mask with 
> enum value.
> 
> 
Yeah I think I shouldn't mix the logic here. I updated it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134189

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


[PATCH] D133933: [clang][dataflow] Modify `transfer` in `DataflowModel` to take `CFGElement` as input instead of `Stmt`.

2022-09-19 Thread weiyi 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 rG41d52c5a7f7a: [clang][dataflow] Modify `transfer` in 
`DataflowModel` to take `CFGElement` as… (authored by wyt).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133933

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
  clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
  clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp


Index: clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
@@ -119,9 +119,7 @@
   static NoopLattice initialElement() { return NoopLattice(); }
 
   void transfer(const CFGElement *E, NoopLattice &, Environment &Env) {
-if (auto S = E->getAs()) {
-  M.transfer(S->getStmt(), Env);
-}
+M.transfer(E, Env);
   }
 
 private:
Index: clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
===
--- clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
+++ clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
@@ -50,7 +50,11 @@
   return CheckDecls.contains(&D);
 }
 
-bool ChromiumCheckModel::transfer(const Stmt *Stmt, Environment &Env) {
+bool ChromiumCheckModel::transfer(const CFGElement *Element, Environment &Env) 
{
+  auto CS = Element->getAs();
+  if (!CS)
+return false;
+  auto Stmt = CS->getStmt();
   if (const auto *Call = dyn_cast(Stmt)) {
 if (const auto *M = dyn_cast(Call->getDirectCallee())) {
   if (isCheckLikeMethod(CheckDecls, *M)) {
Index: clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
===
--- clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
+++ clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
@@ -26,7 +26,7 @@
 class ChromiumCheckModel : public DataflowModel {
 public:
   ChromiumCheckModel() = default;
-  bool transfer(const Stmt *Stmt, Environment &Env) override;
+  bool transfer(const CFGElement *Element, Environment &Env) override;
 
 private:
   /// Declarations for `::logging::CheckError::.*Check`, lazily initialized.
Index: clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -193,8 +193,8 @@
 /// example, a model may capture a type and its related functions.
 class DataflowModel : public Environment::ValueModel {
 public:
-  /// Return value indicates whether the model processed the `Stmt`.
-  virtual bool transfer(const Stmt *Stmt, Environment &Env) = 0;
+  /// Return value indicates whether the model processed the `Element`.
+  virtual bool transfer(const CFGElement *Element, Environment &Env) = 0;
 };
 
 } // namespace dataflow


Index: clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
@@ -119,9 +119,7 @@
   static NoopLattice initialElement() { return NoopLattice(); }
 
   void transfer(const CFGElement *E, NoopLattice &, Environment &Env) {
-if (auto S = E->getAs()) {
-  M.transfer(S->getStmt(), Env);
-}
+M.transfer(E, Env);
   }
 
 private:
Index: clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
===
--- clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
+++ clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
@@ -50,7 +50,11 @@
   return CheckDecls.contains(&D);
 }
 
-bool ChromiumCheckModel::transfer(const Stmt *Stmt, Environment &Env) {
+bool ChromiumCheckModel::transfer(const CFGElement *Element, Environment &Env) {
+  auto CS = Element->getAs();
+  if (!CS)
+return false;
+  auto Stmt = CS->getStmt();
   if (const auto *Call = dyn_cast(Stmt)) {
 if (const auto *M = dyn_cast(Call->getDirectCallee())) {
   if (isCheckLikeMethod(CheckDecls, *M)) {
Index: clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
===
--- clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
+++ clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
@@ -26,7 +26,7 @@
 class ChromiumCheckModel : public DataflowM

[clang] 41d52c5 - [clang][dataflow] Modify `transfer` in `DataflowModel` to take `CFGElement` as input instead of `Stmt`.

2022-09-19 Thread Wei Yi Tee via cfe-commits

Author: Wei Yi Tee
Date: 2022-09-19T18:40:29Z
New Revision: 41d52c5a7f7ad1acf8e84ad6d7f04813c1a5a7ec

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

LOG: [clang][dataflow] Modify `transfer` in `DataflowModel` to take 
`CFGElement` as input instead of `Stmt`.

To keep API of transfer functions consistent.

The single use of this transfer function in `ChromiumCheckModel` is also 
updated.

Reviewed By: gribozavr2, sgatev

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

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
index 098c13cf4e35a..cbd20ad9ee568 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -193,8 +193,8 @@ runDataflowAnalysis(
 /// example, a model may capture a type and its related functions.
 class DataflowModel : public Environment::ValueModel {
 public:
-  /// Return value indicates whether the model processed the `Stmt`.
-  virtual bool transfer(const Stmt *Stmt, Environment &Env) = 0;
+  /// Return value indicates whether the model processed the `Element`.
+  virtual bool transfer(const CFGElement *Element, Environment &Env) = 0;
 };
 
 } // namespace dataflow

diff  --git 
a/clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h 
b/clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
index 93c427bd1ddc6..e65f40b0b726e 100644
--- a/clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
+++ b/clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
@@ -26,7 +26,7 @@ namespace dataflow {
 class ChromiumCheckModel : public DataflowModel {
 public:
   ChromiumCheckModel() = default;
-  bool transfer(const Stmt *Stmt, Environment &Env) override;
+  bool transfer(const CFGElement *Element, Environment &Env) override;
 
 private:
   /// Declarations for `::logging::CheckError::.*Check`, lazily initialized.

diff  --git a/clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp 
b/clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
index 3910847316a59..f457964fb1324 100644
--- a/clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
+++ b/clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
@@ -50,7 +50,11 @@ bool isCheckLikeMethod(llvm::SmallDenseSet &CheckDecls,
   return CheckDecls.contains(&D);
 }
 
-bool ChromiumCheckModel::transfer(const Stmt *Stmt, Environment &Env) {
+bool ChromiumCheckModel::transfer(const CFGElement *Element, Environment &Env) 
{
+  auto CS = Element->getAs();
+  if (!CS)
+return false;
+  auto Stmt = CS->getStmt();
   if (const auto *Call = dyn_cast(Stmt)) {
 if (const auto *M = dyn_cast(Call->getDirectCallee())) {
   if (isCheckLikeMethod(CheckDecls, *M)) {

diff  --git a/clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
index 574366963bd67..1e149db9b44e7 100644
--- a/clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
@@ -119,9 +119,7 @@ class ModelAdaptorAnalysis
   static NoopLattice initialElement() { return NoopLattice(); }
 
   void transfer(const CFGElement *E, NoopLattice &, Environment &Env) {
-if (auto S = E->getAs()) {
-  M.transfer(S->getStmt(), Env);
-}
+M.transfer(E, Env);
   }
 
 private:



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


[PATCH] D134189: [CUDA][HIP] Fix new driver crashing when using -save-temps in RDC-mode

2022-09-19 Thread Artem Belevich via Phabricator via cfe-commits
tra accepted this revision.
tra added a comment.
This revision is now accepted and ready to land.

LGTM with a few nits.




Comment at: clang/include/clang/Driver/Action.h:304
 
+/// Add a action along with the associated toolchain, bound arch, and
+/// offload kinds.

Nit: Add a*n* action



Comment at: clang/include/clang/Driver/Action.h:307
+void add(Action &A, const ToolChain &TC, const char *BoundArch,
+ unsigned Mask);
+

Nit: `OffloadKindMask`?



Comment at: clang/lib/Driver/Action.cpp:320
+if (OKind & Mask)
+  DeviceOffloadKinds.push_back(OKind);
+}

It would be good to clear processed bits in `Mask` and then assert that it's 
zero after we're done. Otherwise it would be easy to miss handling a new 
offload kind if/when it gets added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134189

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


[PATCH] D134189: [CUDA][HIP] Fix new driver crashing when using -save-temps in RDC-mode

2022-09-19 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 marked 3 inline comments as done.
jhuber6 added inline comments.



Comment at: clang/lib/Driver/Action.cpp:320
+if (OKind & Mask)
+  DeviceOffloadKinds.push_back(OKind);
+}

tra wrote:
> It would be good to clear processed bits in `Mask` and then assert that it's 
> zero after we're done. Otherwise it would be easy to miss handling a new 
> offload kind if/when it gets added.
I was also considering just putting something like this next to the 
declarations since we already do this for the new driver as well.

```
constexpr OffloadKind[] DeviceOffloadingKinds = {OFK_OpenMP, OFK_Cuda, OFK_HIP};
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134189

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


[PATCH] D128465: [llvm] add zstd to `llvm::compression` namespace

2022-09-19 Thread Andrew Kelley via Phabricator via cfe-commits
andrewrk added a comment.

  if(LLVM_ENABLE_ZSTD)
list(APPEND imported_libs zstd::libzstd_shared)
  endif()

This hard codes shared linking which breaks the use case of static linking LLVM.

Also LLVM needs to now include a Findzstd.cmake file or else we get this error:

  CMake Error at cmake/config-ix.cmake:144 (find_package):
By not providing "Findzstd.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "zstd", but
CMake did not find one.
  
Could not find a package configuration file provided by "zstd" with any of
the following names:
  
  zstdConfig.cmake
  zstd-config.cmake
  
Add the installation prefix of "zstd" to CMAKE_PREFIX_PATH or set
"zstd_DIR" to a directory containing one of the above files.  If "zstd"
provides a separate development package or SDK, be sure it has been
installed.
  Call Stack (most recent call first):
CMakeLists.txt:774 (include)

It is impossible to satisfy this dependency when bootstrapping a static build 
of zig without patching LLVM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128465

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


[PATCH] D133935: [clang][dataflow] Refactor `clang/Analysis/FlowSensitive/MatchSwitchTest.cpp`.

2022-09-19 Thread weiyi 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 rG88210b81eed8: [clang][dataflow] Refactor 
`clang/Analysis/FlowSensitive/MatchSwitchTest.cpp`. (authored by wyt).

Changed prior to commit:
  https://reviews.llvm.org/D133935?vs=460371&id=461295#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133935

Files:
  clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
@@ -7,24 +7,15 @@
 //===--===//
 
 #include "clang/Analysis/FlowSensitive/MatchSwitch.h"
-#include "TestingSupport.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/Stmt.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
-#include "clang/Analysis/FlowSensitive/DataflowAnalysis.h"
-#include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
-#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
-#include "clang/Analysis/FlowSensitive/MapLattice.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/StringRef.h"
-#include "llvm/ADT/Twine.h"
-#include "llvm/Support/Error.h"
-#include "llvm/Testing/ADT/StringMapEntry.h"
-#include "llvm/Testing/Support/Error.h"
-#include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
 #include 
@@ -34,172 +25,114 @@
 
 using namespace clang;
 using namespace dataflow;
+using namespace ast_matchers;
 
 namespace {
-using ::llvm::IsStringMapEntry;
-using ::testing::UnorderedElementsAre;
 
-class BooleanLattice {
-public:
-  BooleanLattice() : Value(false) {}
-  explicit BooleanLattice(bool B) : Value(B) {}
-
-  static BooleanLattice bottom() { return BooleanLattice(false); }
-
-  static BooleanLattice top() { return BooleanLattice(true); }
-
-  LatticeJoinEffect join(BooleanLattice Other) {
-auto Prev = Value;
-Value = Value || Other.Value;
-return Prev == Value ? LatticeJoinEffect::Unchanged
- : LatticeJoinEffect::Changed;
-  }
-
-  friend bool operator==(BooleanLattice LHS, BooleanLattice RHS) {
-return LHS.Value == RHS.Value;
-  }
-
-  friend std::ostream &operator<<(std::ostream &Os, const BooleanLattice &B) {
-Os << B.Value;
-return Os;
-  }
-
-  bool value() const { return Value; }
-
-private:
-  bool Value;
-};
-} // namespace
-
-MATCHER_P(Holds, m,
-  ((negation ? "doesn't hold" : "holds") +
-   llvm::StringRef(" a lattice element that ") +
-   ::testing::DescribeMatcher(m, negation))
-  .str()) {
-  return ExplainMatchResult(m, arg.Lattice, result_listener);
-}
-
-void TransferSetTrue(const DeclRefExpr *,
- const ast_matchers::MatchFinder::MatchResult &,
- TransferState &State) {
-  State.Lattice = BooleanLattice(true);
-}
-
-void TransferSetFalse(const Stmt *,
-  const ast_matchers::MatchFinder::MatchResult &,
-  TransferState &State) {
-  State.Lattice = BooleanLattice(false);
-}
-
-class TestAnalysis : public DataflowAnalysis {
-  MatchSwitch> TransferSwitch;
-
-public:
-  explicit TestAnalysis(ASTContext &Context)
-  : DataflowAnalysis(Context) {
-using namespace ast_matchers;
-TransferSwitch =
-MatchSwitchBuilder>()
-.CaseOf(declRefExpr(to(varDecl(hasName("X",
- TransferSetTrue)
-.CaseOf(callExpr(callee(functionDecl(hasName("Foo",
-  TransferSetFalse)
-.Build();
-  }
-
-  static BooleanLattice initialElement() { return BooleanLattice::bottom(); }
-
-  void transfer(const Stmt *S, BooleanLattice &L, Environment &Env) {
-TransferState State(L, Env);
-TransferSwitch(*S, getASTContext(), State);
-  }
-};
-
-template 
-void RunDataflow(llvm::StringRef Code, Matcher Expectations) {
-  using namespace ast_matchers;
-  using namespace test;
-  ASSERT_THAT_ERROR(
-  checkDataflow(
-  AnalysisInputs(
-  Code, hasName("fun"),
-  [](ASTContext &C, Environment &) { return TestAnalysis(C); })
-  .withASTBuildArgs({"-fsyntax-only", "-std=c++17"}),
-  /*VerifyResults=*/
-  [&Expectations](
-  const llvm::StringMap<
-  DataflowAnalysisState> &Results,
-  const AnalysisOutputs &) { EXPECT_THAT(Results, Expectations); }),
-  llvm::Succeeded());
-}
-
-TEST(MatchSwitchTest, JustX) {
-  std::string Code = R"(
-void fun() {
-  int X = 1;
-  (void)X;
-  // [[

[clang] 88210b8 - [clang][dataflow] Refactor `clang/Analysis/FlowSensitive/MatchSwitchTest.cpp`.

2022-09-19 Thread Wei Yi Tee via cfe-commits

Author: Wei Yi Tee
Date: 2022-09-19T19:10:41Z
New Revision: 88210b81eed803598afeeaa2a60eb26ddbb65435

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

LOG: [clang][dataflow] Refactor 
`clang/Analysis/FlowSensitive/MatchSwitchTest.cpp`.

- Remove use of `runDataflowAnalysis` to keep test isolated.
- Add test for `ASTMatchSwitch`.

Reviewed By: gribozavr2, sgatev

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

Added: 


Modified: 
clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp

Removed: 




diff  --git a/clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
index 42bf5ddec508..eec1c704dbbb 100644
--- a/clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
@@ -7,24 +7,15 @@
 
//===--===//
 
 #include "clang/Analysis/FlowSensitive/MatchSwitch.h"
-#include "TestingSupport.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/Stmt.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
-#include "clang/Analysis/FlowSensitive/DataflowAnalysis.h"
-#include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
-#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
-#include "clang/Analysis/FlowSensitive/MapLattice.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/ADT/StringRef.h"
-#include "llvm/ADT/Twine.h"
-#include "llvm/Support/Error.h"
-#include "llvm/Testing/ADT/StringMapEntry.h"
-#include "llvm/Testing/Support/Error.h"
-#include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
 #include 
@@ -34,172 +25,114 @@
 
 using namespace clang;
 using namespace dataflow;
+using namespace ast_matchers;
 
 namespace {
-using ::llvm::IsStringMapEntry;
-using ::testing::UnorderedElementsAre;
 
-class BooleanLattice {
-public:
-  BooleanLattice() : Value(false) {}
-  explicit BooleanLattice(bool B) : Value(B) {}
-
-  static BooleanLattice bottom() { return BooleanLattice(false); }
-
-  static BooleanLattice top() { return BooleanLattice(true); }
-
-  LatticeJoinEffect join(BooleanLattice Other) {
-auto Prev = Value;
-Value = Value || Other.Value;
-return Prev == Value ? LatticeJoinEffect::Unchanged
- : LatticeJoinEffect::Changed;
-  }
-
-  friend bool operator==(BooleanLattice LHS, BooleanLattice RHS) {
-return LHS.Value == RHS.Value;
-  }
-
-  friend std::ostream &operator<<(std::ostream &Os, const BooleanLattice &B) {
-Os << B.Value;
-return Os;
-  }
-
-  bool value() const { return Value; }
-
-private:
-  bool Value;
-};
-} // namespace
-
-MATCHER_P(Holds, m,
-  ((negation ? "doesn't hold" : "holds") +
-   llvm::StringRef(" a lattice element that ") +
-   ::testing::DescribeMatcher(m, negation))
-  .str()) {
-  return ExplainMatchResult(m, arg.Lattice, result_listener);
-}
-
-void TransferSetTrue(const DeclRefExpr *,
- const ast_matchers::MatchFinder::MatchResult &,
- TransferState &State) {
-  State.Lattice = BooleanLattice(true);
-}
-
-void TransferSetFalse(const Stmt *,
-  const ast_matchers::MatchFinder::MatchResult &,
-  TransferState &State) {
-  State.Lattice = BooleanLattice(false);
-}
-
-class TestAnalysis : public DataflowAnalysis {
-  MatchSwitch> TransferSwitch;
-
-public:
-  explicit TestAnalysis(ASTContext &Context)
-  : DataflowAnalysis(Context) {
-using namespace ast_matchers;
-TransferSwitch =
-MatchSwitchBuilder>()
-.CaseOf(declRefExpr(to(varDecl(hasName("X",
- TransferSetTrue)
-.CaseOf(callExpr(callee(functionDecl(hasName("Foo",
-  TransferSetFalse)
-.Build();
-  }
-
-  static BooleanLattice initialElement() { return BooleanLattice::bottom(); }
-
-  void transfer(const Stmt *S, BooleanLattice &L, Environment &Env) {
-TransferState State(L, Env);
-TransferSwitch(*S, getASTContext(), State);
-  }
-};
-
-template 
-void RunDataflow(llvm::StringRef Code, Matcher Expectations) {
-  using namespace ast_matchers;
-  using namespace test;
-  ASSERT_THAT_ERROR(
-  checkDataflow(
-  AnalysisInputs(
-  Code, hasName("fun"),
-  [](ASTContext &C, Environment &) { return TestAnalysis(C); })
-  .withASTBuildArgs({"-fsyntax-only", "-std=c++17"}),
-  /*VerifyResults=*/
-  [&Expectations](
-  const llvm::StringMap<
-  DataflowAnalysisState> &Result

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

2022-09-19 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added reviewers: rjmccall, efriedma.
aaron.ballman added a comment.

Adding some codegen reviewers for awareness.




Comment at: clang/lib/Basic/Targets/DirectX.h:66
 
+  bool hasBitIntType() const override { return true; }
   bool hasFeature(StringRef Feature) const override {

beanz wrote:
> aaron.ballman wrote:
> > This change requires more testing/thought, IMO -- do you support 128-bit 
> > operations? When we bump that limit to be arbitrarily high, should DX have 
> > the arbitrary limits or do you need to enforce something lower? Have you 
> > considered how you want to pack these into structures or other data layout 
> > considerations?
> Yea, we definitely need to set the max width to 64 for DirectX.
Nothing seems to have handled this comment yet. Be sure to add a Sema test for 
that as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133668

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


[PATCH] D128465: [llvm] add zstd to `llvm::compression` namespace

2022-09-19 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

zstd provides GNU Makefile, CMake, and Meson. The CMake files are only 
installed when configured with CMake. Debian and Ubuntu lack such files.
The pkg-config file libzstd.pc is probably the most portable file. (I have also 
used it for a binutils-gdb patch.)

I think we can then avoid the

  zstdConfig.cmake
  zstd-config.cmake

issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128465

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


[PATCH] D134207: [Clang] Support case and default labels at end of compound statement

2022-09-19 Thread Evgeny Shulgin via Phabricator via cfe-commits
Izaron created this revision.
Izaron added reviewers: clang-language-wg, aaron.ballman, cor3ntin.
Herald added a project: All.
Izaron requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Direct continuation of https://reviews.llvm.org/D133887


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D134207

Files:
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/lib/Parse/ParseStmt.cpp
  clang/test/AST/ast-dump-stmt.c
  clang/test/C/C2x/n2508.c
  clang/test/Parser/c2x-label.c
  clang/test/Parser/cxx2b-label.cpp
  clang/test/Parser/switch-recovery.cpp
  clang/www/c_status.html

Index: clang/www/c_status.html
===
--- clang/www/c_status.html
+++ clang/www/c_status.html
@@ -763,13 +763,7 @@
 
   Free positioning of labels inside compound statements
   https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2508.pdf";>N2508
-
-  Partial
-Clang supports labels at the end of compound statements but does
-not yet support case or default labels at
-the end of a switch statement's compound block.
-  
-
+  Clang 16
 
 
   Clarification request for C17 example of undefined behavior
Index: clang/test/Parser/switch-recovery.cpp
===
--- clang/test/Parser/switch-recovery.cpp
+++ clang/test/Parser/switch-recovery.cpp
@@ -160,15 +160,15 @@
 void missing_statement_case(int x) {
   switch (x) {
 case 1:
-case 0: // expected-error {{label at end of switch compound statement: expected statement}}
-  }
+case 0:
+  } // expected-warning {{label at end of compound statement is a C++2b extension}}
 }
 
 void missing_statement_default(int x) {
   switch (x) {
 case 0:
-default: // expected-error {{label at end of switch compound statement: expected statement}}
-  }
+default:
+  } // expected-warning {{label at end of compound statement is a C++2b extension}}
 }
 
 void pr19022_1() {
@@ -178,9 +178,8 @@
 
 void pr19022_1a(int x) {
   switch(x) {
-  case 1  // expected-error{{expected ':' after 'case'}} \
-  // expected-error{{label at end of switch compound statement: expected statement}}
-  }
+  case 1  // expected-error{{expected ':' after 'case'}}
+  } // expected-warning {{label at end of compound statement is a C++2b extension}}
 }
 
 void pr19022_1b(int x) {
@@ -210,9 +209,9 @@
 
 void pr19022_5(int x) {
   switch(x) {
-  case 1: case // expected-error{{expected ':' after 'case'}} \
-   // expected-error{{expected statement}}
-  }  // expected-error{{expected expression}}
+  case 1: case // expected-error{{expected ':' after 'case'}}
+  }  // expected-error{{expected expression}} \
+ // expected-warning {{label at end of compound statement is a C++2b extension}}
 }
 
 namespace pr19022 {
Index: clang/test/Parser/cxx2b-label.cpp
===
--- clang/test/Parser/cxx2b-label.cpp
+++ clang/test/Parser/cxx2b-label.cpp
@@ -1,7 +1,7 @@
 // RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx2b -std=c++2b -Wpre-c++2b-compat %s
 // RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx20 -std=c++20 %s
 
-void foo() {
+void test_label_in_func() {
 label1:
 int x;
 label2:
@@ -9,3 +9,23 @@
 label3: label4: label5:
 } // cxx20-warning {{label at end of compound statement is a C++2b extension}} \
  cxx2b-warning {{label at end of compound statement is incompatible with C++ standards before C++2b}}
+
+int test_label_in_switch(int v) {
+switch (v) {
+case 1:
+return 1;
+case 2:
+return 2;
+case 3: case 4: case 5:
+} // cxx20-warning {{label at end of compound statement is a C++2b extension}} \
+ cxx2b-warning {{label at end of compound statement is incompatible with C++ standards before C++2b}}
+
+switch (v) {
+case 6:
+return 6;
+default:
+} // cxx20-warning {{label at end of compound statement is a C++2b extension}} \
+ cxx2b-warning {{label at end of compound statement is incompatible with C++ standards before C++2b}}
+
+return 0;
+}
Index: clang/test/Parser/c2x-label.c
===
--- clang/test/Parser/c2x-label.c
+++ clang/test/Parser/c2x-label.c
@@ -1,10 +1,30 @@
 // RUN: %clang_cc1 -fsyntax-only -std=c17 -Wc2x-compat -verify=c17 %s
 // RUN: %clang_cc1 -fsyntax-only -std=c2x -Wpre-c2x-compat -verify=c2x %s
 
-void foo() {
+void test_label_in_func() {
 int x;
 label1:
 x = 1;
 label2: label3: label4:
 } // c17-warning {{label at end of compound statement is a C2x extension}} \
  c2x-warning {{label at end of compound statement is incompatible with C standards before C2x}}
+
+int test_label_in_switch(int v) {
+switch (v) {
+case 1:
+return 1;
+case 2:
+return 2;
+case 3:

  1   2   >