[PATCH] D95852: [clangd] Report xref for base methods.

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 created this revision.
Herald added subscribers: kadircet, arphaman.
usaxena95 requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang.

See: https://github.com/clangd/clangd/issues/668

  struct A { virtual void foo() = 0; };
  struct B : A { void foo() override; };

Find refs on `B::foo()` will show:

- decls of `A::foo()` (new)
- decls of `B::foo()`
- refs to `A::foo()` (new)
- refs to `B::foo()`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95852

Files:
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp

Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -1883,6 +1883,29 @@
   checkFindRefs(Test, /*UseIndex=*/true);
 }
 
+TEST(FindReferences, RefsToBaseMethod) {
+  llvm::StringRef Test =
+  R"cpp(
+class BaseBase {
+public:
+  virtual void func();
+};
+class Base : public BaseBase {
+public:
+  void [[func]]() override;
+};
+class Derived : public Base {
+public:
+  void $decl[[fu^nc]]() override;
+};
+void test(BaseBase* BB, Base* B, Derived* D) {
+  BB->func();  // refs to base's base method are not reported.
+  B->[[func]]();  // References to the base method.
+  D->[[func]]();
+})cpp";
+  checkFindRefs(Test, /*UseIndex=*/true);
+}
+
 TEST(FindReferences, MainFileReferencesOnly) {
   llvm::StringRef Test =
   R"cpp(
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -1300,7 +1300,7 @@
 return {};
   }
 
-  llvm::DenseSet IDs;
+  llvm::DenseSet IDs, BaseMethod;
 
   const auto *IdentifierAtCursor =
   syntax::spelledIdentifierTouching(*CurLoc, AST.getTokens());
@@ -1347,9 +1347,13 @@
 if (const auto *CMD = llvm::dyn_cast(ND)) {
   if (CMD->isVirtual())
 if (IdentifierAtCursor && SM.getSpellingLoc(CMD->getLocation()) ==
-  IdentifierAtCursor->location())
+  IdentifierAtCursor->location()) {
   if (auto ID = getSymbolID(CMD))
 OverriddenBy.Subjects.insert(ID);
+  for (const NamedDecl *Base : CMD->overridden_methods())
+if (auto ID = getSymbolID(Base))
+  BaseMethod.insert(ID);
+}
 }
   }
 }
@@ -1407,7 +1411,8 @@
 }
   }
   // Now query the index for references from other files.
-  auto QueryIndex = [&](llvm::DenseSet IDs, bool AllowAttributes) {
+  auto QueryIndex = [&](llvm::DenseSet IDs, bool AllowAttributes,
+bool AllowMainFileSymbols) {
 RefsRequest Req;
 Req.IDs = std::move(IDs);
 Req.Limit = Limit;
@@ -1419,7 +1424,8 @@
 return;
   auto LSPLoc = toLSPLocation(R.Location, *MainFilePath);
   // Avoid indexed results for the main file - the AST is authoritative.
-  if (!LSPLoc || LSPLoc->uri.file() == *MainFilePath)
+  if (!LSPLoc ||
+  (!AllowMainFileSymbols && LSPLoc->uri.file() == *MainFilePath))
 return;
   ReferencesResult::Reference Result;
   Result.Loc = std::move(*LSPLoc);
@@ -1434,12 +1440,17 @@
   Results.References.push_back(std::move(Result));
 });
   };
-  QueryIndex(std::move(IDs), /*AllowAttributes=*/true);
+  QueryIndex(std::move(IDs), /*AllowAttributes=*/true,
+ /*AllowMainFileSymbols=*/false);
+  // For a virtual method: Occurrences of BaseMethod should be treated as refs
+  // and not as decl/def. Allow symbols from main file since AST does not report
+  // these.
+  QueryIndex(std::move(BaseMethod), /*AllowAttributes=*/false,
+ /*AllowMainFileSymbols=*/true);
   if (Results.References.size() > Limit) {
 Results.HasMore = true;
 Results.References.resize(Limit);
   }
-  // FIXME: Report refs of base methods.
   return Results;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D95808: [test] Use host platform specific error message substitution in lit tests - continued

[James Henderson via Phabricator via cfe-commits]

jhenderson added a comment.

I think you need to add the new values to the list of recognised substitutions 
in the documentation?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95808

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

[PATCH] D95771: [clang-tidy] fix modernize-loop-convert to retain needed array-like operator[]

[Conrad Poelman via Phabricator via cfe-commits]

poelmanc updated this revision to Diff 320704.
poelmanc marked an inline comment as done.
poelmanc added a comment.

Fix formatting, add suggested test case (which works.)


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

https://reviews.llvm.org/D95771

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
  
clang-tools-extra/test/clang-tidy/checkers/modernize-loop-convert-multidimensional.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize-loop-convert-multidimensional.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-loop-convert-multidimensional.cpp
@@ -0,0 +1,79 @@
+// RUN: %check_clang_tidy %s modernize-loop-convert %t
+
+template 
+struct Vector {
+  using iterator = T*;
+  unsigned size() const;
+  const T &operator[](int) const;
+  T &operator[](int);
+  T *begin();
+  T *end();
+  const T *begin() const;
+  const T *end() const;
+};
+
+template 
+void copyArg(T);
+
+class TestArrayOfVector {
+  Vector W[2];
+
+  void foo() const {
+for (int I = 0; I < W[0].size(); ++I) {
+  if (W[0][I])
+copyArg(W[0][I]);
+}
+// CHECK-MESSAGES: :[[@LINE-4]]:5: warning: use range-based for loop
+// CHECK-FIXES: for (int I : W[0]) {
+// CHECK-FIXES-NEXT: if (I)
+// CHECK-FIXES-NEXT: copyArg(I);
+  }
+};
+
+class TestVectorOfVector {
+  Vector> X;
+
+  void foo() const {
+for (int J = 0; J < X[0].size(); ++J) {
+  if (X[0][J])
+copyArg(X[0][J]);
+}
+// CHECK-MESSAGES: :[[@LINE-4]]:5: warning: use range-based for loop
+// CHECK-FIXES: for (int J : X[0]) {
+// CHECK-FIXES-NEXT: if (J)
+// CHECK-FIXES-NEXT: copyArg(J);
+  }
+};
+
+void testVectorOfVectorOfVector() {
+  Vector>> Y;
+  for (int J = 0; J < Y[3].size(); ++J) {
+if (Y[3][J][7])
+  copyArg(Y[3][J][8]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-4]]:3: warning: use range-based for loop
+  // CHECK-FIXES: for (auto & J : Y[3]) {
+  // CHECK-FIXES-NEXT: if (J[7])
+  // CHECK-FIXES-NEXT: copyArg(J[8]);
+
+  for (int J = 0; J < Y[3][4].size(); ++J) {
+if (Y[3][4][J])
+  copyArg(Y[3][4][J]);
+  }
+  // CHECK-MESSAGES: :[[@LINE-4]]:3: warning: use range-based for loop
+  // CHECK-FIXES: for (int J : Y[3][4]) {
+  // CHECK-FIXES-NEXT: if (J)
+  // CHECK-FIXES-NEXT: copyArg(J);
+}
+
+void testVectorOfVectorIterator() {
+  Vector> Z;
+  for (Vector::iterator it = Z[4].begin(); it != Z[4].end();  ++it) {
+if (*it)
+  copyArg(*it);
+  }
+  // CHECK-MESSAGES: :[[@LINE-4]]:3: warning: use range-based for loop
+  // CHECK-FIXES: for (int & it : Z[4]) {
+  // CHECK-FIXES-NEXT: if (it)
+  // CHECK-FIXES-NEXT: copyArg(it);
+}
Index: clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
===
--- clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
+++ clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
@@ -722,10 +722,11 @@
   if (isa(ContainerExpr)) {
 ContainerString = "this";
   } else {
-// For CXXOperatorCallExpr (e.g. vector_ptr->size()), its first argument is
-// the class object (vector_ptr) we are targeting.
+// For CXXOperatorCallExpr such as vector_ptr->size() we want the class
+// object vector_ptr, but for vector[2] we need the whole expression.
 if (const auto* E = dyn_cast(ContainerExpr))
-  ContainerExpr = E->getArg(0);
+  if (E->getOperator() != OO_Subscript)
+ContainerExpr = E->getArg(0);
 ContainerString =
 getStringFromRange(Context->getSourceManager(), Context->getLangOpts(),
ContainerExpr->getSourceRange());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D77811: [clangd] Implement semanticTokens modifiers

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

In D77811#2533815 , @sammccall wrote:

> Introducing nonstandard kinds is **backwards-incompatible**. If the client 
> doesn't understand primitiveType, then the token kind is now completely 
> unknown. This could be a regression from the current state (type).

Good point. I guess, if we're aiming for backwards compatibility, we'll want to 
do most of our future customization via modifiers, since those will gracefully 
degrade to the highlighting for base kind for clients that don't recongize them.

>> That said... for typedef specifically, I wonder if it actually makes more 
>> sense as a modifier than a kind. That is, have the kind be the target type 
>> (falling back to Unknown/Dependent if we don't know), and have a modifier 
>> flag for "the type is referred to via an alias" (as opposed to "the type is 
>> referred to directly"). WDYT?
>
> Agree. Do you think it should be the *same* modifier as `deduced` which I 
> included here?

Conceptually, they seem distinct to me.

> (In a similar vein, there's an argument for pointer, ref, rvalue-ref as 
> modifiers)

Indeed. I'm definitely happy to defer type modifiers like these (including 
typedef) to a future patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77811

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

[PATCH] D95849: [FileCheck] Default --allow-unused-prefixes to false

[James Henderson via Phabricator via cfe-commits]

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

I assume this now runs cleanly. If so, LGTM. Probably worth mentioning on the 
mailing list thread too, so wrap up that conversation. By the way, did we ever 
figure out how many of the failures were genuine bugs versus deliberate 
isntances?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95849

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

[PATCH] D95776: [OpenCL] Add macro definitions of OpenCL C 3.0 features

[Anton Zabaznov via Phabricator via cfe-commits]

azabaznov updated this revision to Diff 320708.
azabaznov added a comment.

Rebased


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95776

Files:
  clang/include/clang/Basic/OpenCLExtensions.def
  clang/lib/Basic/Targets.cpp
  clang/lib/Headers/opencl-c-base.h
  clang/lib/Headers/opencl-c.h
  clang/test/SemaOpenCL/features.cl

Index: clang/test/SemaOpenCL/features.cl
===
--- /dev/null
+++ clang/test/SemaOpenCL/features.cl
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -cl-std=CL1.1
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -cl-std=CL1.2
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -cl-std=CL2.0
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -cl-std=CL2.0 -finclude-default-header
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -cl-std=CL2.0 -cl-ext=+__opencl_c_pipes
+
+// All features are unsupported
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -verify -cl-std=CL3.0
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -verify -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes -DPIPES
+
+// expected-no-diagnostics
+
+// FULL OpenCL profile
+#ifndef __opencl_c_int64
+#pragma error "Macro __opencl_c_int64 should be defined"
+#endif
+
+#ifdef PIPES
+ #ifndef __opencl_c_pipes
+  #pragma error "Macro __opencl_c_pipes should be defined"
+ #endif
+#else
+ #ifdef __opencl_c_pipes
+  #pragma error "Macro __opencl_c_pipes should not be defined"
+ #endif
+#endif
Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -17157,6 +17157,20 @@
 // Disable any extensions we may have enabled previously.
 #pragma OPENCL EXTENSION all : disable
 
+#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200)
+#undef __opencl_c_pipes
+#undef __opencl_c_generic_address_space
+#undef __opencl_c_work_group_collective_functions
+#undef __opencl_c_atomic_order_acq_rel
+#undef __opencl_c_atomic_order_seq_cst
+#undef __opencl_c_atomic_scope_device
+#undef __opencl_c_atomic_scope_all_devices
+#undef __opencl_c_device_enqueue
+#undef __opencl_c_read_write_images
+#undef __opencl_c_program_scope_global_variables
+#undef __opencl_c_images
+#endif
+
 #undef __cnfn
 #undef __ovld
 #endif //_OPENCL_H_
Index: clang/lib/Headers/opencl-c-base.h
===
--- clang/lib/Headers/opencl-c-base.h
+++ clang/lib/Headers/opencl-c-base.h
@@ -24,6 +24,21 @@
 #endif // defined(__SPIR__)
 #endif // (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 200)
 
+// Define feature macros for OpenCL C 2.0
+#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200)
+#define __opencl_c_pipes 1
+#define __opencl_c_generic_address_space 1
+#define __opencl_c_work_group_collective_functions 1
+#define __opencl_c_atomic_order_acq_rel 1
+#define __opencl_c_atomic_order_seq_cst 1
+#define __opencl_c_atomic_scope_device 1
+#define __opencl_c_atomic_scope_all_devices 1
+#define __opencl_c_device_enqueue 1
+#define __opencl_c_read_write_images 1
+#define __opencl_c_program_scope_global_variables 1
+#define __opencl_c_images 1
+#endif
+
 // built-in scalar data types:
 
 /**
Index: clang/lib/Basic/Targets.cpp
===
--- clang/lib/Basic/Targets.cpp
+++ clang/lib/Basic/Targets.cpp
@@ -720,7 +720,9 @@
 /// and language version
 void TargetInfo::getOpenCLFeatureDefines(const LangOptions &Opts,
  MacroBuilder &Builder) const {
-
+  // FIXME: OpenCL options which affect language semantics/syntax
+  // should be moved into LangOptions, thus macro definitions of
+  // such options is better to be done in clang::InitializePreprocessor
   auto defineOpenCLExtMacro = [&](llvm::StringRef Name, unsigned AvailVer,
   unsigned CoreVersions,
   unsigned OptionalVersions) {
@@ -737,7 +739,6 @@
   defineOpenCLExtMacro(#Ext, Avail, Core, Opt);
 #include "clang/Basic/OpenCLExtensions.def"
 
-  // FIXME: OpenCL options which affect language semantics/syntax
-  // should be moved into LangOptions, thus macro definitions of
-  // such options is better to be done in clang::InitializePreprocessor
+  // Assume compiling for FULL profile
+  Builder.defineMacro("__opencl_c_int64");
 }
Index: clang/include/clang/Basic/OpenCLExtensions.def
===
--- clang/include/clang/Basic/OpenCLExtensions.def
+++ clang/include/clang/Basic/OpenCLExtensions.def
@@ -64,7 +64,7 @@
 OPENCL_EXTENSION(cl_khr_fp16, 100)
 OPENCL_EXTENSION(cl_khr_int64_base_atomics, 100)
 OPENCL_EXTENSION(cl_khr_int64_extended_atomics, 100)
-OPENCL_GENERIC_EXTENSION(cl_khr_3d_image_writes, 100, OCL

[PATCH] D95778: [OpenCL] Introduce new language options for OpenCL keywords.

[Anton Zabaznov via Phabricator via cfe-commits]

azabaznov updated this revision to Diff 320709.
azabaznov added a comment.

Rebased


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95778

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Sema/SemaType.cpp


Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2060,10 +2060,9 @@
   !PointeeType->isSamplerT() &&
   !PointeeType.hasAddressSpace())
 PointeeType = S.getASTContext().getAddrSpaceQualType(
-PointeeType,
-S.getLangOpts().OpenCLCPlusPlus || S.getLangOpts().OpenCLVersion == 200
-? LangAS::opencl_generic
-: LangAS::opencl_private);
+PointeeType, S.getLangOpts().OpenCLGenericKeyword
+ ? LangAS::opencl_generic
+ : LangAS::opencl_private);
   return PointeeType;
 }
 
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -3894,8 +3894,7 @@
   isInvalid = DS.SetTypeAltiVecBool(true, Loc, PrevSpec, DiagID, Policy);
   break;
 case tok::kw_pipe:
-  if (!getLangOpts().OpenCL || (getLangOpts().OpenCLVersion < 200 &&
-!getLangOpts().OpenCLCPlusPlus)) {
+  if (!getLangOpts().OpenCLPipeKeyword) {
 // OpenCL 2.0 defined this keyword. OpenCL 1.2 and earlier should
 // support the "pipe" word as identifier.
 Tok.getIdentifierInfo()->revertTokenIDToIdentifier();
@@ -4017,8 +4016,7 @@
 case tok::kw___generic:
   // generic address space is introduced only in OpenCL v2.0
   // see OpenCL C Spec v2.0 s6.5.5
-  if (Actions.getLangOpts().OpenCLVersion < 200 &&
-  !Actions.getLangOpts().OpenCLCPlusPlus) {
+  if (!Actions.getLangOpts().OpenCLGenericKeyword) {
 DiagID = diag::err_opencl_unknown_type_specifier;
 PrevSpec = Tok.getIdentifierInfo()->getNameStart();
 isInvalid = true;
@@ -5070,8 +5068,7 @@
   default: return false;
 
   case tok::kw_pipe:
-return (getLangOpts().OpenCL && getLangOpts().OpenCLVersion >= 200) ||
-   getLangOpts().OpenCLCPlusPlus;
+return getLangOpts().OpenCLPipeKeyword;
 
   case tok::identifier:   // foo::bar
 // Unfortunate hack to support "Class.factoryMethod" notation.
@@ -5599,8 +5596,7 @@
   if (Kind == tok::star || Kind == tok::caret)
 return true;
 
-  if (Kind == tok::kw_pipe &&
-  ((Lang.OpenCL && Lang.OpenCLVersion >= 200) || Lang.OpenCLCPlusPlus))
+  if (Kind == tok::kw_pipe && Lang.OpenCLPipeKeyword)
 return true;
 
   if (!Lang.CPlusPlus)
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -2092,6 +2092,9 @@
 Opts.ZVector = 0;
 Opts.setDefaultFPContractMode(LangOptions::FPM_On);
 Opts.OpenCLCPlusPlus = Opts.CPlusPlus;
+Opts.OpenCLPipeKeyword = Opts.OpenCLCPlusPlus || Opts.OpenCLVersion == 200;
+Opts.OpenCLGenericKeyword =
+Opts.OpenCLCPlusPlus || Opts.OpenCLVersion == 200;
 
 // Include default header file for OpenCL.
 if (Opts.IncludeDefaultHeader) {
Index: clang/include/clang/Basic/LangOptions.def
===
--- clang/include/clang/Basic/LangOptions.def
+++ clang/include/clang/Basic/LangOptions.def
@@ -215,6 +215,8 @@
 LANGOPT(OpenCLVersion , 32, 0, "OpenCL C version")
 LANGOPT(OpenCLCPlusPlus   , 1, 0, "C++ for OpenCL")
 LANGOPT(OpenCLCPlusPlusVersion , 32, 0, "C++ for OpenCL version")
+LANGOPT(OpenCLGenericKeyword, 1, 0, "OpenCL generic keyword")
+LANGOPT(OpenCLPipeKeyword   , 1, 0, "OpenCL pipe keyword")
 LANGOPT(NativeHalfType, 1, 0, "Native half type support")
 LANGOPT(NativeHalfArgsAndReturns, 1, 0, "Native half args and returns")
 LANGOPT(HalfArgsAndReturns, 1, 0, "half args and returns")


Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2060,10 +2060,9 @@
   !PointeeType->isSamplerT() &&
   !PointeeType.hasAddressSpace())
 PointeeType = S.getASTContext().getAddrSpaceQualType(
-PointeeType,
-S.getLangOpts().OpenCLCPlusPlus || S.getLangOpts().OpenCLVersion == 200
-? LangAS::opencl_generic
-: LangAS::opencl_private);
+PointeeType, S.getLangOpts().OpenCLGenericKeyword
+ ? LangAS::opencl_generic
+ : LangAS::opencl_private);
   return PointeeType;
 }
 
Index: clang/lib/Parse/ParseDecl.cpp
===

[PATCH] D95776: [OpenCL] Add macro definitions of OpenCL C 3.0 features

[Anton Zabaznov via Phabricator via cfe-commits]

azabaznov updated this revision to Diff 320710.
azabaznov added a comment.

Rebased one more time


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95776

Files:
  clang/include/clang/Basic/OpenCLExtensions.def
  clang/lib/Basic/Targets.cpp
  clang/lib/Headers/opencl-c-base.h
  clang/lib/Headers/opencl-c.h
  clang/test/SemaOpenCL/features.cl

Index: clang/test/SemaOpenCL/features.cl
===
--- /dev/null
+++ clang/test/SemaOpenCL/features.cl
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -cl-std=CL1.1
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -cl-std=CL1.2
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -cl-std=CL2.0
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -cl-std=CL2.0 -finclude-default-header
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -cl-std=CL2.0 -cl-ext=+__opencl_c_pipes
+
+// All features are unsupported
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -verify -cl-std=CL3.0
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -verify -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes -DPIPES
+
+// expected-no-diagnostics
+
+// FULL OpenCL profile
+#ifndef __opencl_c_int64
+#pragma error "Macro __opencl_c_int64 should be defined"
+#endif
+
+#ifdef PIPES
+ #ifndef __opencl_c_pipes
+  #pragma error "Macro __opencl_c_pipes should be defined"
+ #endif
+#else
+ #ifdef __opencl_c_pipes
+  #pragma error "Macro __opencl_c_pipes should not be defined"
+ #endif
+#endif
Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -17157,6 +17157,20 @@
 // Disable any extensions we may have enabled previously.
 #pragma OPENCL EXTENSION all : disable
 
+#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200)
+#undef __opencl_c_pipes
+#undef __opencl_c_generic_address_space
+#undef __opencl_c_work_group_collective_functions
+#undef __opencl_c_atomic_order_acq_rel
+#undef __opencl_c_atomic_order_seq_cst
+#undef __opencl_c_atomic_scope_device
+#undef __opencl_c_atomic_scope_all_devices
+#undef __opencl_c_device_enqueue
+#undef __opencl_c_read_write_images
+#undef __opencl_c_program_scope_global_variables
+#undef __opencl_c_images
+#endif
+
 #undef __cnfn
 #undef __ovld
 #endif //_OPENCL_H_
Index: clang/lib/Headers/opencl-c-base.h
===
--- clang/lib/Headers/opencl-c-base.h
+++ clang/lib/Headers/opencl-c-base.h
@@ -24,6 +24,21 @@
 #endif // defined(__SPIR__)
 #endif // (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 200)
 
+// Define feature macros for OpenCL C 2.0
+#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200)
+#define __opencl_c_pipes 1
+#define __opencl_c_generic_address_space 1
+#define __opencl_c_work_group_collective_functions 1
+#define __opencl_c_atomic_order_acq_rel 1
+#define __opencl_c_atomic_order_seq_cst 1
+#define __opencl_c_atomic_scope_device 1
+#define __opencl_c_atomic_scope_all_devices 1
+#define __opencl_c_device_enqueue 1
+#define __opencl_c_read_write_images 1
+#define __opencl_c_program_scope_global_variables 1
+#define __opencl_c_images 1
+#endif
+
 // built-in scalar data types:
 
 /**
Index: clang/lib/Basic/Targets.cpp
===
--- clang/lib/Basic/Targets.cpp
+++ clang/lib/Basic/Targets.cpp
@@ -720,7 +720,9 @@
 /// and language version
 void TargetInfo::getOpenCLFeatureDefines(const LangOptions &Opts,
  MacroBuilder &Builder) const {
-
+  // FIXME: OpenCL options which affect language semantics/syntax
+  // should be moved into LangOptions, thus macro definitions of
+  // such options is better to be done in clang::InitializePreprocessor
   auto defineOpenCLExtMacro = [&](llvm::StringRef Name, unsigned AvailVer,
   unsigned CoreVersions,
   unsigned OptionalVersions) {
@@ -737,7 +739,6 @@
   defineOpenCLExtMacro(#Ext, Avail, Core, Opt);
 #include "clang/Basic/OpenCLExtensions.def"
 
-  // FIXME: OpenCL options which affect language semantics/syntax
-  // should be moved into LangOptions, thus macro definitions of
-  // such options is better to be done in clang::InitializePreprocessor
+  // Assume compiling for FULL profile
+  Builder.defineMacro("__opencl_c_int64");
 }
Index: clang/include/clang/Basic/OpenCLExtensions.def
===
--- clang/include/clang/Basic/OpenCLExtensions.def
+++ clang/include/clang/Basic/OpenCLExtensions.def
@@ -64,7 +64,7 @@
 OPENCL_EXTENSION(cl_khr_fp16, 100)
 OPENCL_EXTENSION(cl_khr_int64_base_atomics, 100)
 OPENCL_EXTENSION(cl_khr_int64_extended_atomics, 100)
-OPENCL_GENERIC_EXTENSION(cl_khr_3d_image_wr

[PATCH] D95852: [clangd] Report xref for base methods.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/clangd/unittests/XRefsTests.cpp:1902
+void test(BaseBase* BB, Base* B, Derived* D) {
+  BB->func();  // refs to base's base method are not reported.
+  B->[[func]]();  // References to the base method.

ah, this is a good case!  I think we should include the base's base method as 
part of the refs -- because BB->func() can actually call D::func if BB points 
to a `Derived` object.

the fix is to add ids from `overridden_methods` recursively.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95852

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

[clang] 0479c53 - [dllimport] Honor always_inline when deciding whether a dllimport function should be available for inlining (PR48925)

[Hans Wennborg via cfe-commits]

Author: Hans Wennborg
Date: 2021-02-02T10:28:32+01:00
New Revision: 0479c53b6c5224c16bdc78cb014e76c0b0dbc6f9

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

LOG: [dllimport] Honor always_inline when deciding whether a dllimport function 
should be available for inlining (PR48925)

Normally, Clang will not make dllimport functions available for inlining
if they reference non-imported symbols, as this can lead to confusing
link errors. But if the function is marked always_inline, the user
presumably knows what they're doing and the attribute should be honored.

Differential revision: https://reviews.llvm.org/D95673

Added: 


Modified: 
clang/lib/CodeGen/CodeGenModule.cpp
clang/test/CodeGenCXX/dllimport.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 31afbc6b4262..c9cf4076579b 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -3031,7 +3031,7 @@ bool CodeGenModule::shouldEmitFunction(GlobalDecl GD) {
   if (CodeGenOpts.OptimizationLevel == 0 && !F->hasAttr())
 return false;
 
-  if (F->hasAttr()) {
+  if (F->hasAttr() && !F->hasAttr()) {
 // Check whether it would be safe to inline this dllimport function.
 DLLImportFunctionVisitor Visitor;
 Visitor.TraverseFunctionDecl(const_cast(F));

diff  --git a/clang/test/CodeGenCXX/dllimport.cpp 
b/clang/test/CodeGenCXX/dllimport.cpp
index 1aa5a23ec6ca..6113b28ed5c7 100644
--- a/clang/test/CodeGenCXX/dllimport.cpp
+++ b/clang/test/CodeGenCXX/dllimport.cpp
@@ -386,6 +386,13 @@ __declspec(dllimport) inline void FunctionWithNormalVar() 
{ static int x = 42; }
 USE(FunctionWithTLSVar)
 USE(FunctionWithNormalVar)
 
+// always_inline and __force_inline take precedence.
+__declspec(dllimport) inline int ReferencingNonImportedFuncAlwaysInline() 
__attribute__((always_inline)) { return NonImportedFunc(); }
+USE(ReferencingNonImportedFuncAlwaysInline)
+// MO1-DAG: define available_externally dllimport i32 
@"?ReferencingNonImportedFuncAlwaysInline@@YAHXZ"
+__declspec(dllimport) __forceinline int 
ReferencingNonImportedFuncForceInline() { return NonImportedFunc(); }
+USE(ReferencingNonImportedFuncForceInline)
+// MO1-DAG: define available_externally dllimport i32 
@"?ReferencingNonImportedFuncForceInline@@YAHXZ"
 
 
//===--===//
 // Function templates



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

[PATCH] D95673: [dllimport] Honor always_inline when deciding whether a dllimport function should be available for inlining (PR48925)

[Hans Wennborg 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 rG0479c53b6c52: [dllimport] Honor always_inline when deciding 
whether a dllimport function… (authored by hans).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95673

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGenCXX/dllimport.cpp


Index: clang/test/CodeGenCXX/dllimport.cpp
===
--- clang/test/CodeGenCXX/dllimport.cpp
+++ clang/test/CodeGenCXX/dllimport.cpp
@@ -386,6 +386,13 @@
 USE(FunctionWithTLSVar)
 USE(FunctionWithNormalVar)
 
+// always_inline and __force_inline take precedence.
+__declspec(dllimport) inline int ReferencingNonImportedFuncAlwaysInline() 
__attribute__((always_inline)) { return NonImportedFunc(); }
+USE(ReferencingNonImportedFuncAlwaysInline)
+// MO1-DAG: define available_externally dllimport i32 
@"?ReferencingNonImportedFuncAlwaysInline@@YAHXZ"
+__declspec(dllimport) __forceinline int 
ReferencingNonImportedFuncForceInline() { return NonImportedFunc(); }
+USE(ReferencingNonImportedFuncForceInline)
+// MO1-DAG: define available_externally dllimport i32 
@"?ReferencingNonImportedFuncForceInline@@YAHXZ"
 
 
//===--===//
 // Function templates
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -3031,7 +3031,7 @@
   if (CodeGenOpts.OptimizationLevel == 0 && !F->hasAttr())
 return false;
 
-  if (F->hasAttr()) {
+  if (F->hasAttr() && !F->hasAttr()) {
 // Check whether it would be safe to inline this dllimport function.
 DLLImportFunctionVisitor Visitor;
 Visitor.TraverseFunctionDecl(const_cast(F));


Index: clang/test/CodeGenCXX/dllimport.cpp
===
--- clang/test/CodeGenCXX/dllimport.cpp
+++ clang/test/CodeGenCXX/dllimport.cpp
@@ -386,6 +386,13 @@
 USE(FunctionWithTLSVar)
 USE(FunctionWithNormalVar)
 
+// always_inline and __force_inline take precedence.
+__declspec(dllimport) inline int ReferencingNonImportedFuncAlwaysInline() __attribute__((always_inline)) { return NonImportedFunc(); }
+USE(ReferencingNonImportedFuncAlwaysInline)
+// MO1-DAG: define available_externally dllimport i32 @"?ReferencingNonImportedFuncAlwaysInline@@YAHXZ"
+__declspec(dllimport) __forceinline int ReferencingNonImportedFuncForceInline() { return NonImportedFunc(); }
+USE(ReferencingNonImportedFuncForceInline)
+// MO1-DAG: define available_externally dllimport i32 @"?ReferencingNonImportedFuncForceInline@@YAHXZ"
 
 //===--===//
 // Function templates
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -3031,7 +3031,7 @@
   if (CodeGenOpts.OptimizationLevel == 0 && !F->hasAttr())
 return false;
 
-  if (F->hasAttr()) {
+  if (F->hasAttr() && !F->hasAttr()) {
 // Check whether it would be safe to inline this dllimport function.
 DLLImportFunctionVisitor Visitor;
 Visitor.TraverseFunctionDecl(const_cast(F));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D95778: [OpenCL] Introduce new language options for OpenCL keywords.

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added a comment.

LGTM, but perhaps you can add a test that has each keyword disabled?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95778

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

[PATCH] D94961: [OpenMP] Add OpenMP offloading toolchain for AMDGPU

[Pushpinder Singh via Phabricator via cfe-commits]

pdhaliwal updated this revision to Diff 320722.
pdhaliwal added a comment.

Addressed review comments.

- Combined the toolchain creation logic for nvptx and amdgcn
- Replaced -Xopenmp-target with -emit-llvm-bc inside AMDGPUOpenMP.cpp
- Removed opt from pipeline


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94961

Files:
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/AMDGPU.h
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
  clang/lib/Driver/ToolChains/HIP.h
  clang/test/Driver/amdgpu-openmp-toolchain.c

Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- /dev/null
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -0,0 +1,36 @@
+// REQUIRES: amdgpu-registered-target
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s 2>&1 \
+// RUN:   | FileCheck %s
+
+// verify the tools invocations
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" "c"{{.*}}
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" "ir"{{.*}}
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "amdgcn-amd-amdhsa"{{.*}}"-target-cpu" "gfx906" "-fcuda-is-device" "-emit-llvm-bc"{{.*}}
+// CHECK: llvm-link{{.*}}"-o" "{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc"
+// CHECK: llc{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc" "-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-filetype=obj" "-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
+// CHECK: lld{{.*}}"-flavor" "gnu" "--no-undefined" "-shared" "-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}.out" "{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
+// CHECK: clang-offload-wrapper{{.*}}"-target" "x86_64-unknown-linux-gnu" "-o" "{{.*}}a-{{.*}}.bc" {{.*}}amdgpu-openmp-toolchain-{{.*}}.out"
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-o" "{{.*}}a-{{.*}}.o" "-x" "ir" "{{.*}}a-{{.*}}.bc"
+// CHECK: ld{{.*}}"-o" "a.out"{{.*}}"{{.*}}amdgpu-openmp-toolchain-{{.*}}.o" "{{.*}}a-{{.*}}.o" "-lomp" "-lomptarget"
+
+// RUN:   %clang -ccc-print-phases --target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-PHASES %s
+// phases
+// CHECK-PHASES: 0: input, "{{.*}}amdgpu-openmp-toolchain.c", c, (host-openmp)
+// CHECK-PHASES: 1: preprocessor, {0}, cpp-output, (host-openmp)
+// CHECK-PHASES: 2: compiler, {1}, ir, (host-openmp)
+// CHECK-PHASES: 3: backend, {2}, assembler, (host-openmp)
+// CHECK-PHASES: 4: assembler, {3}, object, (host-openmp)
+// CHECK-PHASES: 5: input, "{{.*}}amdgpu-openmp-toolchain.c", c, (device-openmp)
+// CHECK-PHASES: 6: preprocessor, {5}, cpp-output, (device-openmp)
+// CHECK-PHASES: 7: compiler, {6}, ir, (device-openmp)
+// CHECK-PHASES: 8: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (amdgcn-amd-amdhsa)" {7}, ir
+// CHECK-PHASES: 9: backend, {8}, assembler, (device-openmp)
+// CHECK-PHASES: 10: assembler, {9}, object, (device-openmp)
+// CHECK-PHASES: 11: linker, {10}, image, (device-openmp)
+// CHECK-PHASES: 12: offload, "device-openmp (amdgcn-amd-amdhsa)" {11}, image
+// CHECK-PHASES: 13: clang-offload-wrapper, {12}, ir, (host-openmp)
+// CHECK-PHASES: 14: backend, {13}, assembler, (host-openmp)
+// CHECK-PHASES: 15: assembler, {14}, object, (host-openmp)
+// CHECK-PHASES: 16: linker, {4, 15}, image, (host-openmp)
+
Index: clang/lib/Driver/ToolChains/HIP.h
===
--- clang/lib/Driver/ToolChains/HIP.h
+++ clang/lib/Driver/ToolChains/HIP.h
@@ -71,15 +71,6 @@
   void addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
  llvm::opt::ArgStringList &CC1Args,
  Action::OffloadKind DeviceOffloadKind) const override;
-
-  bool useIntegratedAs() const override { return true; }
-  bool isCrossCompiling() const override { return true; }
-  bool isPICDefault() const override { return false; }
-  bool isPIEDefault() const override { return false; }
-  bool isPICDefaultForced() const override { return false; }
-  bool SupportsProfiling() const override { return false; }
-  bool IsMathErrnoDefault() const override { return false; }
-
   void addClangWarningOptions(llvm::opt::ArgStringList &CC1Args) const override;
   CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList &Args) const override;
   void
Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
===
--- /dev/null
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
@@ -0,0 +1,106 @@
+//===- AMDGPUOpenMP.h - AMDGPUOpenMP ToolChain Implementation -*- C++ -*---===//
+//
+// Part of the

[PATCH] D94961: [OpenMP] Add OpenMP offloading toolchain for AMDGPU

[Pushpinder Singh via Phabricator via cfe-commits]

pdhaliwal marked 3 inline comments as done.
pdhaliwal added a comment.

After addressing the review comments, I have internally verified changes on few 
simple test programs. They seem to be working fine.




Comment at: clang/lib/Driver/Driver.cpp:3004
+}
+  }
+  // amdgcn does not support linking of object files, therefore we skip

jdoerfert wrote:
> This does not look right. IsAMDGCN is not a question that should be answered 
> by a `-Xopenmp-target` flag. 
> 
> In general, why skip these passes here. Isn't what you really want to do, 
> pass `-emit-llvm[-bc]` to the device compilation job?
I have removed the logic from here instead now I have added -emit-llvm-bc using 
addClangTargetOptions in AMDGPUOpenMP.



Comment at: clang/test/Driver/amdgpu-openmp-toolchain.c:2
+// REQUIRES: amdgpu-registered-target
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx906 %s 2>&1 \
+// RUN:   | FileCheck %s

jdoerfert wrote:
> Would this at all work without the march flag?
This would not work without -march flag as amdgcn is not forward/backward 
compatible and there is currently no way to detect system gpu arch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94961

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

[PATCH] D94955: [clang-format] Treat ForEachMacros as loops

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

I'm never going to be the one to accept patches where people change tests 
without making it really clear why they are changing it. You have to prove you 
are not regressing behaviour, I work on the Beyonce rule, "if you liked it you 
should have put a test on it"

That means if you are changing that rule you are breaking what someone else 
did, so you have to work doubly hard to a) minimize the test changes and b) 
prove you haven't broken anything.

I'm always suspension why people change a `verifyFormat` to an `EXPECT_EQ` to 
me it smells as if you tried it with verifyFormat and it didn't work so hacked 
a way around it.. ultimately this tends to leads to a bug further down the road.




Comment at: clang/unittests/Format/FormatTest.cpp:996
+  FormatStyle Style = getLLVMStyle();
+  EXPECT_NE("void f() {\n"
+"  foreach (Item *item, itemlist) {}\n"

verifyFormat



Comment at: clang/unittests/Format/FormatTest.cpp:1021
   FormatStyle::SBPO_ControlStatementsExceptForEachMacros;
   verifyFormat("void f() {\n"
+   "  foreach(Item *item, itemlist) {\n"

Please don't change existing tests without asserting why its ok to now do that.

I don't see a single assert that asserts that AllowShortLoopsOnASingleLine  is 
true at this point

As you are now changing this behaviour you need to add a non short loop to 
prove that you haven't made a mistake for the non short loop case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94955

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

[PATCH] D94961: [OpenMP] Add OpenMP offloading toolchain for AMDGPU

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added inline comments.



Comment at: clang/test/Driver/amdgpu-openmp-toolchain.c:2
+// REQUIRES: amdgpu-registered-target
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx906 %s 2>&1 \
+// RUN:   | FileCheck %s

pdhaliwal wrote:
> jdoerfert wrote:
> > Would this at all work without the march flag?
> This would not work without -march flag as amdgcn is not forward/backward 
> compatible and there is currently no way to detect system gpu arch.
The command line invocation openmp needs `-fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906` could be friendlier.

Auto-detecting march is convenient in general but probably bad for clang tests 
as we want them to run on systems that don't have an amdgpu installed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94961

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

[PATCH] D95523: [OpenCL] Add cl_khr_subgroup_ballot to TableGen BIFs

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added inline comments.



Comment at: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl:35
+// Enable extensions that are enabled in opencl-c-base.h.
+#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 200)
+#define cl_khr_subgroup_ballot 1

Anastasia wrote:
> Not related to this patch - I think we should have included `opencl-c-base.h` 
> by default when passing `-fdeclare-opencl-builtins` or do you see any issues 
> with that?
> 
> 
That's something we probably want to do in the future indeed.



Comment at: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl:141
+kernel void extended_subgroup(global uint4 *out) {
+  out[0] = get_sub_group_eq_mask();
+#if __OPENCL_C_VERSION__ < CL_VERSION_2_0 && !defined(__OPENCL_CPP_VERSION__)

Anastasia wrote:
> I appreciate we haven't addressed the standard header testing holistically 
> yet and this functionality was added in `opencl-c.h` without testing the 
> functions, but would it be better to test each function at least here?
> 
> Even though the final goal should be testing all overloads, this is outside 
> of the scope of this work that is closing the gap between `opencl-c.h` and 
> this experimental function declaration mechanism.
> but would it be better to test each function at least here?

I think that defeats the purpose of this test.  This test is meant to test the 
basic functionality of `-fdeclare-opencl-builtins`.  It is not a completeness 
test.

A completeness test shouldn't be tied to `-fdeclare-opencl-builtins` alone; 
such a test should also be run against `opencl-c.h`, so this would be the wrong 
test to turn into a completeness test in my opinion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95523

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

[PATCH] D95860: [clang][Frontend] Fix a crash in DiagnosticRenderer.

[Balázs Kéri via Phabricator via cfe-commits]

balazske created this revision.
Herald added subscribers: martong, gamesh411, Szelethus, dkrupp.
Herald added a reviewer: Szelethus.
balazske requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Displaying the problem range could crash if the begin and end of a
range is in different files or macros. After the change such range
is displayed only as the beginning location.

There is a bug for this problem:
https://bugs.llvm.org/show_bug.cgi?id=46540


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95860

Files:
  clang/lib/Frontend/DiagnosticRenderer.cpp
  clang/test/Analysis/crash-diagnostic-renderer.cpp


Index: clang/test/Analysis/crash-diagnostic-renderer.cpp
===
--- /dev/null
+++ clang/test/Analysis/crash-diagnostic-renderer.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -verify %s
+
+// This case reproduces a problem that is shown here:
+// https://bugs.llvm.org/show_bug.cgi?id=46540
+// No assertion should happen in this case.
+
+// expected-error@13{{'b' does not refer to a type name in pseudo-destructor 
expression; expected the name of type 'volatile long'}}
+// expected-error@13{{expected ')'}}
+// expected-note@13{{to match this '('}}
+// expected-error@13{{reference to pseudo-destructor must be called; did you 
mean to call it with no arguments?}}
+// expected-error@13{{cannot initialize a variable of type 'volatile long' 
with an rvalue of type 'void'}}
+// expected-error@13{{expected ';' after top level declarator}}
+volatile long a ( a .~b
Index: clang/lib/Frontend/DiagnosticRenderer.cpp
===
--- clang/lib/Frontend/DiagnosticRenderer.cpp
+++ clang/lib/Frontend/DiagnosticRenderer.cpp
@@ -394,6 +394,9 @@
   }
 }
 
+if (Begin.isInvalid() || End.isInvalid() || BeginFileID != EndFileID)
+  continue;
+
 // Do the backtracking.
 SmallVector CommonArgExpansions;
 computeCommonMacroArgExpansionFileIDs(Begin, End, SM, CommonArgExpansions);


Index: clang/test/Analysis/crash-diagnostic-renderer.cpp
===
--- /dev/null
+++ clang/test/Analysis/crash-diagnostic-renderer.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -verify %s
+
+// This case reproduces a problem that is shown here:
+// https://bugs.llvm.org/show_bug.cgi?id=46540
+// No assertion should happen in this case.
+
+// expected-error@13{{'b' does not refer to a type name in pseudo-destructor expression; expected the name of type 'volatile long'}}
+// expected-error@13{{expected ')'}}
+// expected-note@13{{to match this '('}}
+// expected-error@13{{reference to pseudo-destructor must be called; did you mean to call it with no arguments?}}
+// expected-error@13{{cannot initialize a variable of type 'volatile long' with an rvalue of type 'void'}}
+// expected-error@13{{expected ';' after top level declarator}}
+volatile long a ( a .~b
Index: clang/lib/Frontend/DiagnosticRenderer.cpp
===
--- clang/lib/Frontend/DiagnosticRenderer.cpp
+++ clang/lib/Frontend/DiagnosticRenderer.cpp
@@ -394,6 +394,9 @@
   }
 }
 
+if (Begin.isInvalid() || End.isInvalid() || BeginFileID != EndFileID)
+  continue;
+
 // Do the backtracking.
 SmallVector CommonArgExpansions;
 computeCommonMacroArgExpansionFileIDs(Begin, End, SM, CommonArgExpansions);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D94961: [OpenMP] Add OpenMP offloading toolchain for AMDGPU

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

Looks much simpler, thanks!




Comment at: clang/lib/Driver/Driver.cpp:755
+  *this, TT, *HostTC, C.getInputArgs(), 
Action::OFK_OpenMP);
+else if (TT.isAMDGCN())
+  DeviceTC =

Minor suggestion,
```
if (TT.isNVPTX() {
 ...
} else {
  assert(TT.isAMDGCN());
  ...
}```

? Semantically equivalent, but `if () else if ()` looks like there is a missing 
else clause.



Comment at: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp:43
+
+static void addOptLevelArgs(const llvm::opt::ArgList &Args,
+llvm::opt::ArgStringList &CmdArgs) {

Maybe rename this since opt is no longer involved. addLLCOptArg or similar? 
There's probably the same logic in another toolchain



Comment at: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp:64
+ .Case("g", "1")
+ .Default("2");
+}

Default("0") and update the comment 'we map anything else'


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94961

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

[clang] dc00c96 - [OpenCL] Change extension handling for -fdeclare-opencl-builtins

[Sven van Haastregt via cfe-commits]

Author: Sven van Haastregt
Date: 2021-02-02T11:15:29Z
New Revision: dc00c96b2d1bcae56ef598b614ba65a1cc26c4de

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

LOG: [OpenCL] Change extension handling for -fdeclare-opencl-builtins

Until now, the `-fdeclare-opencl-builtins` option behaved differently
compared to inclusion of `opencl-c.h`: builtins that are part of an
extension were only available if the extension was enabled using the
corresponding pragma.

Builtins that belong to an extension are guarded using a preprocessor
macro (that is named after the extension) in `opencl-c.h`.  Align the
behaviour of `-fdeclare-opencl-builtins` with this.

Co-authored-by: Anastasia Stulova

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

Added: 


Modified: 
clang/lib/Sema/SemaLookup.cpp
clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl

Removed: 




diff  --git a/clang/lib/Sema/SemaLookup.cpp b/clang/lib/Sema/SemaLookup.cpp
index 29038ab9fe1c..3556f07b1fe5 100644
--- a/clang/lib/Sema/SemaLookup.cpp
+++ b/clang/lib/Sema/SemaLookup.cpp
@@ -743,18 +743,6 @@ static void GetOpenCLBuiltinFctOverloads(
   }
 }
 
-/// Add extensions to the function declaration.
-/// \param S (in/out) The Sema instance.
-/// \param BIDecl (in) Description of the builtin.
-/// \param FDecl (in/out) FunctionDecl instance.
-static void AddOpenCLExtensions(Sema &S, const OpenCLBuiltinStruct &BIDecl,
-FunctionDecl *FDecl) {
-  // Fetch extension associated with a function prototype.
-  StringRef E = FunctionExtensionTable[BIDecl.Extension];
-  if (E != "")
-S.setOpenCLExtensionForDecl(FDecl, E);
-}
-
 /// When trying to resolve a function name, if isOpenCLBuiltin() returns a
 /// non-null  pair, then the name is referencing an OpenCL
 /// builtin function.  Add all candidate signatures to the LookUpResult.
@@ -790,6 +778,13 @@ static void InsertOCLBuiltinDeclarationsFromTable(Sema &S, 
LookupResult &LR,
 (OpenCLVersion >= OpenCLBuiltin.MaxVersion))
   continue;
 
+// Ignore this builtin function if it carries an extension macro that is
+// not defined. This indicates that the extension is not supported by the
+// target, so the builtin function should not be available.
+StringRef Ext = FunctionExtensionTable[OpenCLBuiltin.Extension];
+if (!Ext.empty() && !S.getPreprocessor().isMacroDefined(Ext))
+  continue;
+
 SmallVector RetTypes;
 SmallVector, 5> ArgTypes;
 
@@ -843,8 +838,6 @@ static void InsertOCLBuiltinDeclarationsFromTable(Sema &S, 
LookupResult &LR,
   if (!S.getLangOpts().OpenCLCPlusPlus)
 NewOpenCLBuiltin->addAttr(OverloadableAttr::CreateImplicit(Context));
 
-  AddOpenCLExtensions(S, OpenCLBuiltin, NewOpenCLBuiltin);
-
   LR.addDecl(NewOpenCLBuiltin);
 }
   }

diff  --git a/clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl 
b/clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
index 3cf963eb2fba..773998a60941 100644
--- a/clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ b/clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -38,26 +38,6 @@ kernel void test_pointers(volatile global void *global_p, 
global const int4 *a)
 
   prefetch(a, 2);
 
-  atom_add((volatile __global int *)global_p, i);
-#if !defined(__OPENCL_CPP_VERSION__) && __OPENCL_C_VERSION__ < CL_VERSION_1_1
-// expected-error@-2{{no matching function for call to 'atom_add'}}
-
-// There are two potential definitions of the function "atom_add", both are
-// currently disabled because the associated extension is disabled.
-// expected-note@-6{{candidate function not viable: cannot pass pointer to 
address space '__global' as a pointer to address space '__local' in 1st 
argument}}
-// expected-note@-7{{candidate function not viable: no known conversion}}
-// expected-note@-8{{candidate function not viable: no known conversion}}
-// expected-note@-9{{candidate function not viable: no known conversion}}
-// expected-note@-10{{candidate unavailable as it requires OpenCL extension 
'cl_khr_global_int32_base_atomics' to be enabled}}
-// expected-note@-11{{candidate unavailable as it requires OpenCL extension 
'cl_khr_global_int32_base_atomics' to be enabled}}
-// expected-note@-12{{candidate unavailable as it requires OpenCL extension 
'cl_khr_int64_base_atomics' to be enabled}}
-// expected-note@-13{{candidate unavailable as it requires OpenCL extension 
'cl_khr_int64_base_atomics' to be enabled}}
-#endif
-
-#if __OPENCL_C_VERSION__ < CL_VERSION_1_1
-#pragma OPENCL EXTENSION cl_khr_global_int32_base_atomics : enable
-#endif
-
   atom_add((volatile __global int *)global_p, i);
   atom_cmpxchg((volatile __global unsigned int *)global_p, ui, ui);
 }
@@ -146,11 +126,9 @@ kernel void basic_image_writeonly(write_only 
image1d_buffer_t image_

[PATCH] D95616: [OpenCL] Change extension handling for -fdeclare-opencl-builtins

[Sven van Haastregt 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 rGdc00c96b2d1b: [OpenCL] Change extension handling for 
-fdeclare-opencl-builtins (authored by svenvh).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95616

Files:
  clang/lib/Sema/SemaLookup.cpp
  clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl


Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -38,26 +38,6 @@
 
   prefetch(a, 2);
 
-  atom_add((volatile __global int *)global_p, i);
-#if !defined(__OPENCL_CPP_VERSION__) && __OPENCL_C_VERSION__ < CL_VERSION_1_1
-// expected-error@-2{{no matching function for call to 'atom_add'}}
-
-// There are two potential definitions of the function "atom_add", both are
-// currently disabled because the associated extension is disabled.
-// expected-note@-6{{candidate function not viable: cannot pass pointer to 
address space '__global' as a pointer to address space '__local' in 1st 
argument}}
-// expected-note@-7{{candidate function not viable: no known conversion}}
-// expected-note@-8{{candidate function not viable: no known conversion}}
-// expected-note@-9{{candidate function not viable: no known conversion}}
-// expected-note@-10{{candidate unavailable as it requires OpenCL extension 
'cl_khr_global_int32_base_atomics' to be enabled}}
-// expected-note@-11{{candidate unavailable as it requires OpenCL extension 
'cl_khr_global_int32_base_atomics' to be enabled}}
-// expected-note@-12{{candidate unavailable as it requires OpenCL extension 
'cl_khr_int64_base_atomics' to be enabled}}
-// expected-note@-13{{candidate unavailable as it requires OpenCL extension 
'cl_khr_int64_base_atomics' to be enabled}}
-#endif
-
-#if __OPENCL_C_VERSION__ < CL_VERSION_1_1
-#pragma OPENCL EXTENSION cl_khr_global_int32_base_atomics : enable
-#endif
-
   atom_add((volatile __global int *)global_p, i);
   atom_cmpxchg((volatile __global unsigned int *)global_p, ui, ui);
 }
@@ -146,11 +126,9 @@
 
 kernel void basic_subgroup(global uint *out) {
   out[0] = get_sub_group_size();
-#if defined(__OPENCL_CPP_VERSION__)
-  // expected-error@-2{{no matching function for call to 'get_sub_group_size'}}
-  // expected-note@-3{{candidate unavailable as it requires OpenCL extension 
'cl_khr_subgroups' to be enabled}}
-#else
-  // expected-error@-5{{use of declaration 'get_sub_group_size' requires 
cl_khr_subgroups extension to be enabled}}
+#if __OPENCL_C_VERSION__ <= CL_VERSION_1_2 && !defined(__OPENCL_CPP_VERSION__)
+  // expected-error@-2{{implicit declaration of function 'get_sub_group_size' 
is invalid in OpenCL}}
+  // expected-error@-3{{implicit conversion changes signedness}}
 #endif
 }
 
Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -743,18 +743,6 @@
   }
 }
 
-/// Add extensions to the function declaration.
-/// \param S (in/out) The Sema instance.
-/// \param BIDecl (in) Description of the builtin.
-/// \param FDecl (in/out) FunctionDecl instance.
-static void AddOpenCLExtensions(Sema &S, const OpenCLBuiltinStruct &BIDecl,
-FunctionDecl *FDecl) {
-  // Fetch extension associated with a function prototype.
-  StringRef E = FunctionExtensionTable[BIDecl.Extension];
-  if (E != "")
-S.setOpenCLExtensionForDecl(FDecl, E);
-}
-
 /// When trying to resolve a function name, if isOpenCLBuiltin() returns a
 /// non-null  pair, then the name is referencing an OpenCL
 /// builtin function.  Add all candidate signatures to the LookUpResult.
@@ -790,6 +778,13 @@
 (OpenCLVersion >= OpenCLBuiltin.MaxVersion))
   continue;
 
+// Ignore this builtin function if it carries an extension macro that is
+// not defined. This indicates that the extension is not supported by the
+// target, so the builtin function should not be available.
+StringRef Ext = FunctionExtensionTable[OpenCLBuiltin.Extension];
+if (!Ext.empty() && !S.getPreprocessor().isMacroDefined(Ext))
+  continue;
+
 SmallVector RetTypes;
 SmallVector, 5> ArgTypes;
 
@@ -843,8 +838,6 @@
   if (!S.getLangOpts().OpenCLCPlusPlus)
 NewOpenCLBuiltin->addAttr(OverloadableAttr::CreateImplicit(Context));
 
-  AddOpenCLExtensions(S, OpenCLBuiltin, NewOpenCLBuiltin);
-
   LR.addDecl(NewOpenCLBuiltin);
 }
   }


Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -38,26 +38,6 @@
 
   prefetch(a, 2);
 
-  atom_add((volatile __global int

[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D89909#2534790 , @bader wrote:

>> Regarding SYCLDevice and SYCLAddrSpaceMap I am still not very convinced 
>> about the flow. Have you had any design discussion regarding this already 
>> that you could point to?
>
> We discussed this with you in https://github.com/intel/llvm/pull/1039/.

I can't see.

>> My main concern is that I am not sure it fits with the main design of Clang 
>> - producing IR that is to be consumed by multiple targets rather than only 
>> one specific target or even an external tool. Why do you add a triple 
>> component that is used only for one target SPIR:
>>
>> How would existing toolchains that consume LLVM-IR for SPIR cope with the 
>> fact that the Default address space is different for C++ and SYCL.
>
> High level languages differences doesn't matter for toolchains consuming LLVM 
> IR - it can python, D or SYCL. Toolchains are assuming that LLVM IR follows 
> the sematic defined in SPIR-1.2 document - 
> https://www.khronos.org/registry/SPIR/specs/spir_spec-1.2.pdf.

I can't understand what you mean by "doesn't matter"? If you compiler from C++ 
you get one address space as `Default` and if you compile from SYCL you get a 
different one for the same target - how do you expect the toolchain consuming 
the IR to handle that? Certainly this is not how LLVM was designed. LLVM 
expects the same address spaces to be used with one target for all languages.

FYI, the document is no longer describing the current SPIR target adequately as 
implementation deviated quite a bit from the original documentation.

>> Why is changing of `the address space map necessary for SPIR but not the 
>> other targets?
>
> The main reason is the difference in handling Default address space in C++ 
> for OpenCL mode and SYCL. C++ for OpenCL doesn't always deduce address space 
> and there are cases when Default is used and SPIR target maps it AS 0 
> (equivalent of SPIR-V Function storage class). This lead to inconsistencies 
> like reported here: https://bugs.llvm.org/show_bug.cgi?id=45472.
>
> SYCL doesn't deduce language address space at all relies on mapping Default 
> in LLVM AS equivalent of SPIR-V generic.
>
> NOTE: other GPU targets like AMDGPU and NVPTX do the same i.e. maps Default 
> language AS to LLVM IR AS equivalent of SPIR-V generic, so there is no need 
> to update. I believe SPIR target must apply the same mapping.

Generic address space in Clang is a logical concept added for OpenCL to 
implement the following logical concept .
https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#the-generic-address-space

Targets are allowed to map it to any physical address space (it is very 
reasonable to map it to `Default`) but it is only used for restricted use cases 
i.e. pointers or references. `Default` address space is where objects are put 
by default - for example in C++ everything is mapped to this address space. I 
don't see why you just replace `Default` by OpenCL generic. It has been added 
for a very different purpose.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89909

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

[PATCH] D95812: [clangd] Report only decl of overridding method in xref.

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 updated this revision to Diff 320737.
usaxena95 marked 2 inline comments as done.
usaxena95 added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95812

Files:
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/XRefs.h
  clang-tools-extra/clangd/unittests/XRefsTests.cpp

Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -1706,6 +1706,15 @@
   for (const auto &R : T.ranges("decl"))
 ExpectedLocations.push_back(
 AllOf(RangeIs(R), AttrsAre(ReferencesResult::Declaration)));
+  for (const auto &R : T.ranges("overridedecl"))
+ExpectedLocations.push_back(AllOf(
+RangeIs(R),
+AttrsAre(ReferencesResult::Declaration | ReferencesResult::Override)));
+  for (const auto &R : T.ranges("overridedef"))
+ExpectedLocations.push_back(
+AllOf(RangeIs(R), AttrsAre(ReferencesResult::Declaration |
+   ReferencesResult::Definition |
+   ReferencesResult::Override)));
   EXPECT_THAT(
   findReferences(AST, T.point(), 0, UseIndex ? TU.index().get() : nullptr)
   .References,
@@ -1871,10 +1880,11 @@
 };
 class Derived : public Base {
 public:
-  void [[func]]() override;
+  void $overridedecl[[func]]() override;
 };
+void Derived::$overridedef[[func]]() {}
 void test(Derived* D) {
-  D->[[func]]();
+  D->func();  // No references to the overrides.
 })cpp";
   checkFindRefs(Test, /*UseIndex=*/true);
 }
Index: clang-tools-extra/clangd/XRefs.h
===
--- clang-tools-extra/clangd/XRefs.h
+++ clang-tools-extra/clangd/XRefs.h
@@ -83,6 +83,8 @@
   enum ReferenceAttributes : unsigned {
 Declaration = 1 << 0,
 Definition = 1 << 1,
+// The occurrence is an override of the target base method.
+Override = 1 << 2,
   };
   struct Reference {
 Location Loc;
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -1300,7 +1300,7 @@
 return {};
   }
 
-  llvm::DenseSet IDs, Overrides;
+  llvm::DenseSet IDs;
 
   const auto *IdentifierAtCursor =
   syntax::spelledIdentifierTouching(*CurLoc, AST.getTokens());
@@ -1339,25 +1339,19 @@
   if (auto ID = getSymbolID(D))
 Targets.insert(ID);
 
+RelationsRequest OverriddenBy;
 if (Index) {
-  RelationsRequest FindOverrides;
-  FindOverrides.Predicate = RelationKind::OverriddenBy;
+  OverriddenBy.Predicate = RelationKind::OverriddenBy;
   for (const NamedDecl *ND : Decls) {
-// Special case: virtual void meth^od() = 0 includes refs of overrides.
+// Special case: Inlcude declaration of overridding methods.
 if (const auto *CMD = llvm::dyn_cast(ND)) {
-  if (CMD->isPure())
+  if (CMD->isVirtual())
 if (IdentifierAtCursor && SM.getSpellingLoc(CMD->getLocation()) ==
   IdentifierAtCursor->location())
   if (auto ID = getSymbolID(CMD))
-FindOverrides.Subjects.insert(ID);
+OverriddenBy.Subjects.insert(ID);
 }
   }
-  if (!FindOverrides.Subjects.empty())
-Index->relations(FindOverrides,
- [&](const SymbolID &Subject, const Symbol &Object) {
-   Overrides.insert(Object.ID);
- });
-  Targets.insert(Overrides.begin(), Overrides.end());
 }
 
 // We traverse the AST to find references in the main file.
@@ -1376,17 +1370,37 @@
   ReferencesResult::Reference Result;
   Result.Loc.range = Ref.range(SM);
   Result.Loc.uri = URIMainFile;
-  // Overrides are always considered references, not defs/decls.
-  if (!Overrides.contains(Ref.Target)) {
-if (Ref.Role & static_cast(index::SymbolRole::Declaration))
-  Result.Attributes |= ReferencesResult::Declaration;
-// clang-index doesn't report definitions as declarations, but they are.
-if (Ref.Role & static_cast(index::SymbolRole::Definition))
-  Result.Attributes |=
-  ReferencesResult::Definition | ReferencesResult::Declaration;
-  }
+  if (Ref.Role & static_cast(index::SymbolRole::Declaration))
+Result.Attributes |= ReferencesResult::Declaration;
+  // clang-index doesn't report definitions as declarations, but they are.
+  if (Ref.Role & static_cast(index::SymbolRole::Definition))
+Result.Attributes |=
+ReferencesResult::Definition | Referenc

[PATCH] D94961: [OpenMP] Add OpenMP offloading toolchain for AMDGPU

[Pushpinder Singh via Phabricator via cfe-commits]

pdhaliwal updated this revision to Diff 320740.
pdhaliwal added a comment.

- Use 0 for default -O option
- Rename addOptLevelArgs to addLLCOptArg


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94961

Files:
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/AMDGPU.h
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
  clang/lib/Driver/ToolChains/HIP.h
  clang/test/Driver/amdgpu-openmp-toolchain.c

Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- /dev/null
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -0,0 +1,36 @@
+// REQUIRES: amdgpu-registered-target
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s 2>&1 \
+// RUN:   | FileCheck %s
+
+// verify the tools invocations
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" "c"{{.*}}
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-x" "ir"{{.*}}
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "amdgcn-amd-amdhsa"{{.*}}"-target-cpu" "gfx906" "-fcuda-is-device" "-emit-llvm-bc"{{.*}}
+// CHECK: llvm-link{{.*}}"-o" "{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc"
+// CHECK: llc{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked-{{.*}}.bc" "-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-filetype=obj" "-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
+// CHECK: lld{{.*}}"-flavor" "gnu" "--no-undefined" "-shared" "-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}.out" "{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-{{.*}}.o"
+// CHECK: clang-offload-wrapper{{.*}}"-target" "x86_64-unknown-linux-gnu" "-o" "{{.*}}a-{{.*}}.bc" {{.*}}amdgpu-openmp-toolchain-{{.*}}.out"
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-unknown-linux-gnu"{{.*}}"-o" "{{.*}}a-{{.*}}.o" "-x" "ir" "{{.*}}a-{{.*}}.bc"
+// CHECK: ld{{.*}}"-o" "a.out"{{.*}}"{{.*}}amdgpu-openmp-toolchain-{{.*}}.o" "{{.*}}a-{{.*}}.o" "-lomp" "-lomptarget"
+
+// RUN:   %clang -ccc-print-phases --target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-PHASES %s
+// phases
+// CHECK-PHASES: 0: input, "{{.*}}amdgpu-openmp-toolchain.c", c, (host-openmp)
+// CHECK-PHASES: 1: preprocessor, {0}, cpp-output, (host-openmp)
+// CHECK-PHASES: 2: compiler, {1}, ir, (host-openmp)
+// CHECK-PHASES: 3: backend, {2}, assembler, (host-openmp)
+// CHECK-PHASES: 4: assembler, {3}, object, (host-openmp)
+// CHECK-PHASES: 5: input, "{{.*}}amdgpu-openmp-toolchain.c", c, (device-openmp)
+// CHECK-PHASES: 6: preprocessor, {5}, cpp-output, (device-openmp)
+// CHECK-PHASES: 7: compiler, {6}, ir, (device-openmp)
+// CHECK-PHASES: 8: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, "device-openmp (amdgcn-amd-amdhsa)" {7}, ir
+// CHECK-PHASES: 9: backend, {8}, assembler, (device-openmp)
+// CHECK-PHASES: 10: assembler, {9}, object, (device-openmp)
+// CHECK-PHASES: 11: linker, {10}, image, (device-openmp)
+// CHECK-PHASES: 12: offload, "device-openmp (amdgcn-amd-amdhsa)" {11}, image
+// CHECK-PHASES: 13: clang-offload-wrapper, {12}, ir, (host-openmp)
+// CHECK-PHASES: 14: backend, {13}, assembler, (host-openmp)
+// CHECK-PHASES: 15: assembler, {14}, object, (host-openmp)
+// CHECK-PHASES: 16: linker, {4, 15}, image, (host-openmp)
+
Index: clang/lib/Driver/ToolChains/HIP.h
===
--- clang/lib/Driver/ToolChains/HIP.h
+++ clang/lib/Driver/ToolChains/HIP.h
@@ -71,15 +71,6 @@
   void addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
  llvm::opt::ArgStringList &CC1Args,
  Action::OffloadKind DeviceOffloadKind) const override;
-
-  bool useIntegratedAs() const override { return true; }
-  bool isCrossCompiling() const override { return true; }
-  bool isPICDefault() const override { return false; }
-  bool isPIEDefault() const override { return false; }
-  bool isPICDefaultForced() const override { return false; }
-  bool SupportsProfiling() const override { return false; }
-  bool IsMathErrnoDefault() const override { return false; }
-
   void addClangWarningOptions(llvm::opt::ArgStringList &CC1Args) const override;
   CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList &Args) const override;
   void
Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
===
--- /dev/null
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.h
@@ -0,0 +1,106 @@
+//===- AMDGPUOpenMP.h - AMDGPUOpenMP ToolChain Implementation -*- C++ -*---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license 

[PATCH] D94961: [OpenMP] Add OpenMP offloading toolchain for AMDGPU

[Pushpinder Singh via Phabricator via cfe-commits]

pdhaliwal added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:755
+  *this, TT, *HostTC, C.getInputArgs(), 
Action::OFK_OpenMP);
+else if (TT.isAMDGCN())
+  DeviceTC =

JonChesterfield wrote:
> Minor suggestion,
> ```
> if (TT.isNVPTX() {
>  ...
> } else {
>   assert(TT.isAMDGCN());
>   ...
> }```
> 
> ? Semantically equivalent, but `if () else if ()` looks like there is a 
> missing else clause.
I think, having assert in last else is bit cleaner.  What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94961

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

[PATCH] D94961: [OpenMP] Add OpenMP offloading toolchain for AMDGPU

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:755
+  *this, TT, *HostTC, C.getInputArgs(), 
Action::OFK_OpenMP);
+else if (TT.isAMDGCN())
+  DeviceTC =

pdhaliwal wrote:
> JonChesterfield wrote:
> > Minor suggestion,
> > ```
> > if (TT.isNVPTX() {
> >  ...
> > } else {
> >   assert(TT.isAMDGCN());
> >   ...
> > }```
> > 
> > ? Semantically equivalent, but `if () else if ()` looks like there is a 
> > missing else clause.
> I think, having assert in last else is bit cleaner.  What do you think?
I also prefer the if () else {assert()} construct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94961

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

[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

[Alexey Bader via Phabricator via cfe-commits]

bader updated this revision to Diff 320741.
bader added a comment.

Applied code review suggestions from Anastasia.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89909

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Sema/ParsedAttr.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGenSYCL/address-space-cond-op.cpp
  clang/test/CodeGenSYCL/address-space-of-returns.cpp
  clang/test/CodeGenSYCL/address-space-parameter-conversions.cpp
  clang/test/CodeGenSYCL/address-spaces-struct.cpp
  clang/test/CodeGenSYCL/address-spaces.cpp
  clang/test/SemaSYCL/address-space-parameter-conversions.cpp
  clang/test/SemaTemplate/address_space-dependent.cpp
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/Support/Triple.cpp

Index: llvm/lib/Support/Triple.cpp
===
--- llvm/lib/Support/Triple.cpp
+++ llvm/lib/Support/Triple.cpp
@@ -247,6 +247,8 @@
   case Musl: return "musl";
   case MuslEABI: return "musleabi";
   case MuslEABIHF: return "musleabihf";
+  case SYCLDevice:
+return "sycldevice";
   case Simulator: return "simulator";
   }
 
@@ -554,6 +556,7 @@
   .StartsWith("itanium", Triple::Itanium)
   .StartsWith("cygnus", Triple::Cygnus)
   .StartsWith("coreclr", Triple::CoreCLR)
+  .StartsWith("sycldevice", Triple::SYCLDevice)
   .StartsWith("simulator", Triple::Simulator)
   .StartsWith("macabi", Triple::MacABI)
   .Default(Triple::UnknownEnvironment);
Index: llvm/include/llvm/ADT/Triple.h
===
--- llvm/include/llvm/ADT/Triple.h
+++ llvm/include/llvm/ADT/Triple.h
@@ -222,8 +222,9 @@
 Itanium,
 Cygnus,
 CoreCLR,
+SYCLDevice,
 Simulator, // Simulator variants of other systems, e.g., Apple's iOS
-MacABI, // Mac Catalyst variant of Apple's iOS deployment target.
+MacABI,// Mac Catalyst variant of Apple's iOS deployment target.
 LastEnvironmentType = MacABI
   };
   enum ObjectFormatType {
@@ -497,6 +498,10 @@
isMacCatalystEnvironment()));
   }
 
+  bool isSYCLDeviceEnvironment() const {
+return getEnvironment() == Triple::SYCLDevice;
+  }
+
   bool isOSNetBSD() const {
 return getOS() == Triple::NetBSD;
   }
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 (8388593)}}
+  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388590)}}
 }
 
 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<0x71>();
+  correct<0x7FFFED>();
   tooBig<8388650>(); // expected-note {{in instantiation of function template specialization 'tooBig<8388650>' requested here}}
 
   __attribute__((address_space(1))) char *x;
Index: clang/test/SemaSYCL/address-space-parameter-conversions.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/address-space-parameter-conversions.cpp
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -fsycl -fsycl-is-device -verify -fsyntax-only -x c++ %s
+
+void bar(int &Data) {}
+void bar2(int &Data) {}
+void bar(__attribute__((opencl_private)) int &Data) {}
+void foo(int *Data) {}
+void foo2(int *Data) {}
+void foo(__attribute__((opencl_private)) int *Data) {}
+
+template 
+void tmpl(T *t) {}
+
+void usages() {
+  __attribute__((opencl_global)) int *GLOB;
+  __attribute__((opencl_private)) int *PRIV;
+  __attribute__((opencl_local)) int *LOC;
+  int *NoAS;
+
+  bar(*GLOB);
+  bar2(*GLOB);
+
+  bar(*PRIV);
+  bar2(*PRIV);
+
+  bar(*NoAS);
+  bar2(*NoAS);
+
+  bar(*LOC);
+  bar2(*LOC);
+
+  foo(GLOB);
+  foo2(GLOB);
+  foo(PRIV);
+  foo2(PRIV);
+  foo(NoAS);
+  foo2(NoAS);
+  foo(LOC);
+  foo2(LOC);
+
+  tmpl(GLOB);
+  tmpl(PRIV);
+  tmpl(NoAS);
+  tmpl(LOC);
+
+  (void)static_cast(GLOB);
+  (void)static_cast(GLOB);
+  // FIXME: determine if we can warn on the below conversions.
+  int *i = GLOB;
+  void *v 

[clang-tools-extra] fbeff2e - [clangd] Report only decl of overridding method in xref.

[Utkarsh Saxena via cfe-commits]

Author: Utkarsh Saxena
Date: 2021-02-02T13:06:20+01:00
New Revision: fbeff2ec2bc6e44b92931207b0063f83ff7a3b3a

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

LOG: [clangd] Report only decl of overridding method in xref.

See: https://github.com/clangd/clangd/issues/668

```
struct A { virtual void foo() = 0; };
struct B : A { void foo() override; };
```

Find refs on `A::foo()` will show:
- decls of `A::foo()`
- decls of `B::foo()`
- refs to `A::foo()`
- no refs to `B::foo()`.

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

Added: 


Modified: 
clang-tools-extra/clangd/XRefs.cpp
clang-tools-extra/clangd/XRefs.h
clang-tools-extra/clangd/unittests/XRefsTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/XRefs.cpp 
b/clang-tools-extra/clangd/XRefs.cpp
index 55b55da80fda..b6a0be4a0a0a 100644
--- a/clang-tools-extra/clangd/XRefs.cpp
+++ b/clang-tools-extra/clangd/XRefs.cpp
@@ -1300,7 +1300,7 @@ ReferencesResult findReferences(ParsedAST &AST, Position 
Pos, uint32_t Limit,
 return {};
   }
 
-  llvm::DenseSet IDs, Overrides;
+  llvm::DenseSet IDs;
 
   const auto *IdentifierAtCursor =
   syntax::spelledIdentifierTouching(*CurLoc, AST.getTokens());
@@ -1339,25 +1339,19 @@ ReferencesResult findReferences(ParsedAST &AST, 
Position Pos, uint32_t Limit,
   if (auto ID = getSymbolID(D))
 Targets.insert(ID);
 
+RelationsRequest OverriddenBy;
 if (Index) {
-  RelationsRequest FindOverrides;
-  FindOverrides.Predicate = RelationKind::OverriddenBy;
+  OverriddenBy.Predicate = RelationKind::OverriddenBy;
   for (const NamedDecl *ND : Decls) {
-// Special case: virtual void meth^od() = 0 includes refs of overrides.
+// Special case: Inlcude declaration of overridding methods.
 if (const auto *CMD = llvm::dyn_cast(ND)) {
-  if (CMD->isPure())
+  if (CMD->isVirtual())
 if (IdentifierAtCursor && SM.getSpellingLoc(CMD->getLocation()) ==
   IdentifierAtCursor->location())
   if (auto ID = getSymbolID(CMD))
-FindOverrides.Subjects.insert(ID);
+OverriddenBy.Subjects.insert(ID);
 }
   }
-  if (!FindOverrides.Subjects.empty())
-Index->relations(FindOverrides,
- [&](const SymbolID &Subject, const Symbol &Object) {
-   Overrides.insert(Object.ID);
- });
-  Targets.insert(Overrides.begin(), Overrides.end());
 }
 
 // We traverse the AST to find references in the main file.
@@ -1376,17 +1370,37 @@ ReferencesResult findReferences(ParsedAST &AST, 
Position Pos, uint32_t Limit,
   ReferencesResult::Reference Result;
   Result.Loc.range = Ref.range(SM);
   Result.Loc.uri = URIMainFile;
-  // Overrides are always considered references, not defs/decls.
-  if (!Overrides.contains(Ref.Target)) {
-if (Ref.Role & static_cast(index::SymbolRole::Declaration))
-  Result.Attributes |= ReferencesResult::Declaration;
-// clang-index doesn't report definitions as declarations, but they 
are.
-if (Ref.Role & static_cast(index::SymbolRole::Definition))
-  Result.Attributes |=
-  ReferencesResult::Definition | ReferencesResult::Declaration;
-  }
+  if (Ref.Role & static_cast(index::SymbolRole::Declaration))
+Result.Attributes |= ReferencesResult::Declaration;
+  // clang-index doesn't report definitions as declarations, but they are.
+  if (Ref.Role & static_cast(index::SymbolRole::Definition))
+Result.Attributes |=
+ReferencesResult::Definition | ReferencesResult::Declaration;
   Results.References.push_back(std::move(Result));
 }
+// Add decl/def of overridding methods.
+if (Index && Results.References.size() <= Limit &&
+!OverriddenBy.Subjects.empty())
+  Index->relations(
+  OverriddenBy, [&](const SymbolID &Subject, const Symbol &Object) {
+if (auto LSPLoc =
+toLSPLocation(Object.CanonicalDeclaration, *MainFilePath)) 
{
+  ReferencesResult::Reference Result;
+  Result.Loc = std::move(*LSPLoc);
+  Result.Attributes =
+  ReferencesResult::Declaration | ReferencesResult::Override;
+  Results.References.push_back(std::move(Result));
+}
+if (auto LSPLoc = toLSPLocation(Object.Definition, *MainFilePath)) 
{
+  ReferencesResult::Reference Result;
+  Result.Loc = std::move(*LSPLoc);
+  Result.Attributes = ReferencesResult::Declaration |
+  ReferencesResult::Definition |
+ 

[PATCH] D95812: [clangd] Report only decl of overridding method in xref.

[Utkarsh Saxena 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 rGfbeff2ec2bc6: [clangd] Report only decl of overridding 
method in xref. (authored by usaxena95).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95812

Files:
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/XRefs.h
  clang-tools-extra/clangd/unittests/XRefsTests.cpp

Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -1706,6 +1706,15 @@
   for (const auto &R : T.ranges("decl"))
 ExpectedLocations.push_back(
 AllOf(RangeIs(R), AttrsAre(ReferencesResult::Declaration)));
+  for (const auto &R : T.ranges("overridedecl"))
+ExpectedLocations.push_back(AllOf(
+RangeIs(R),
+AttrsAre(ReferencesResult::Declaration | ReferencesResult::Override)));
+  for (const auto &R : T.ranges("overridedef"))
+ExpectedLocations.push_back(
+AllOf(RangeIs(R), AttrsAre(ReferencesResult::Declaration |
+   ReferencesResult::Definition |
+   ReferencesResult::Override)));
   EXPECT_THAT(
   findReferences(AST, T.point(), 0, UseIndex ? TU.index().get() : nullptr)
   .References,
@@ -1871,10 +1880,11 @@
 };
 class Derived : public Base {
 public:
-  void [[func]]() override;
+  void $overridedecl[[func]]() override;
 };
+void Derived::$overridedef[[func]]() {}
 void test(Derived* D) {
-  D->[[func]]();
+  D->func();  // No references to the overrides.
 })cpp";
   checkFindRefs(Test, /*UseIndex=*/true);
 }
Index: clang-tools-extra/clangd/XRefs.h
===
--- clang-tools-extra/clangd/XRefs.h
+++ clang-tools-extra/clangd/XRefs.h
@@ -83,6 +83,8 @@
   enum ReferenceAttributes : unsigned {
 Declaration = 1 << 0,
 Definition = 1 << 1,
+// The occurrence is an override of the target base method.
+Override = 1 << 2,
   };
   struct Reference {
 Location Loc;
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -1300,7 +1300,7 @@
 return {};
   }
 
-  llvm::DenseSet IDs, Overrides;
+  llvm::DenseSet IDs;
 
   const auto *IdentifierAtCursor =
   syntax::spelledIdentifierTouching(*CurLoc, AST.getTokens());
@@ -1339,25 +1339,19 @@
   if (auto ID = getSymbolID(D))
 Targets.insert(ID);
 
+RelationsRequest OverriddenBy;
 if (Index) {
-  RelationsRequest FindOverrides;
-  FindOverrides.Predicate = RelationKind::OverriddenBy;
+  OverriddenBy.Predicate = RelationKind::OverriddenBy;
   for (const NamedDecl *ND : Decls) {
-// Special case: virtual void meth^od() = 0 includes refs of overrides.
+// Special case: Inlcude declaration of overridding methods.
 if (const auto *CMD = llvm::dyn_cast(ND)) {
-  if (CMD->isPure())
+  if (CMD->isVirtual())
 if (IdentifierAtCursor && SM.getSpellingLoc(CMD->getLocation()) ==
   IdentifierAtCursor->location())
   if (auto ID = getSymbolID(CMD))
-FindOverrides.Subjects.insert(ID);
+OverriddenBy.Subjects.insert(ID);
 }
   }
-  if (!FindOverrides.Subjects.empty())
-Index->relations(FindOverrides,
- [&](const SymbolID &Subject, const Symbol &Object) {
-   Overrides.insert(Object.ID);
- });
-  Targets.insert(Overrides.begin(), Overrides.end());
 }
 
 // We traverse the AST to find references in the main file.
@@ -1376,17 +1370,37 @@
   ReferencesResult::Reference Result;
   Result.Loc.range = Ref.range(SM);
   Result.Loc.uri = URIMainFile;
-  // Overrides are always considered references, not defs/decls.
-  if (!Overrides.contains(Ref.Target)) {
-if (Ref.Role & static_cast(index::SymbolRole::Declaration))
-  Result.Attributes |= ReferencesResult::Declaration;
-// clang-index doesn't report definitions as declarations, but they are.
-if (Ref.Role & static_cast(index::SymbolRole::Definition))
-  Result.Attributes |=
-  ReferencesResult::Definition | ReferencesResult::Declaration;
-  }
+  if (Ref.Role & static_cast(index::SymbolRole::Declaration))
+Result.Attributes |= ReferencesResult::Declaration;
+  // clang-index doesn't report definitions as declarations, but they are.
+  if (Ref.Role & static_cast(index::Sy

[PATCH] D95808: [test] Use host platform specific error message substitution in lit tests - continued

[Abhina Sree via Phabricator via cfe-commits]

abhina.sreeskantharajan updated this revision to Diff 320745.
abhina.sreeskantharajan added a comment.

Thank you for reminding me, I've updated the TestingGuide.rst.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95808

Files:
  clang/test/Analysis/taint-generic.c
  clang/test/Format/style-on-command-line.cpp
  lld/test/COFF/thinlto-emit-imports.ll
  lld/test/ELF/lto/resolution-err.ll
  lld/test/ELF/lto/thinlto-cant-write-index.ll
  lld/test/ELF/lto/thinlto-emit-imports.ll
  llvm/docs/TestingGuide.rst
  llvm/test/tools/llvm-ar/error-opening-permission.test
  llvm/test/tools/llvm-elfabi/fail-file-write.test
  llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml
  llvm/utils/lit/lit/llvm/config.py

Index: llvm/utils/lit/lit/llvm/config.py
===
--- llvm/utils/lit/lit/llvm/config.py
+++ llvm/utils/lit/lit/llvm/config.py
@@ -349,12 +349,18 @@
 if (sys.platform == 'zos'):
 self.config.substitutions.append(('%errc_ENOENT', '\'EDC5129I No such file or directory.\''))
 self.config.substitutions.append(('%errc_EISDIR', '\'EDC5123I Is a directory.\''))
+self.config.substitutions.append(('%errc_EINVAL', '\'EDC5121I Invalid argument.\''))
+self.config.substitutions.append(('%errc_EACCES', '\'EDC5111I Permission denied.\''))
 elif (sys.platform == 'win32'):
 self.config.substitutions.append(('%errc_ENOENT', '\'no such file or directory\''))
 self.config.substitutions.append(('%errc_EISDIR', '\'is a directory\''))
+self.config.substitutions.append(('%errc_EINVAL', '\'invalid argument\''))
+self.config.substitutions.append(('%errc_EACCES', '\'permission denied\''))
 else:
 self.config.substitutions.append(('%errc_ENOENT', '\'No such file or directory\''))
 self.config.substitutions.append(('%errc_EISDIR', '\'Is a directory\''))
+self.config.substitutions.append(('%errc_EINVAL', '\'Invalid argument\''))
+self.config.substitutions.append(('%errc_EACCES', '\'Permission denied\''))
 
 def use_default_substitutions(self):
 tool_patterns = [
Index: llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml
===
--- llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml
+++ llvm/test/tools/yaml2obj/ELF/DWARF/debug-gnu-pubnames.yaml
@@ -225,12 +225,12 @@
 
 ## h) Test that yaml2obj emits an error if 'Descriptor' is missing.
 
-# RUN: not yaml2obj --docnum=8 %s -o %t8.o 2>&1 | FileCheck %s --check-prefix=MISSING-KEY --ignore-case
+# RUN: not yaml2obj --docnum=8 %s -o %t8.o 2>&1 | FileCheck -DMSG=%errc_EINVAL %s --check-prefix=MISSING-KEY --ignore-case
 
 #  MISSING-KEY: YAML:{{.*}}:9: error: missing required key 'Descriptor'
 # MISSING-KEY-NEXT:   - DieOffset: 0x12345678
 # MISSING-KEY-NEXT: ^
-# MISSING-KEY-NEXT: yaml2obj: error: failed to parse YAML input: Invalid argument
+# MISSING-KEY-NEXT: yaml2obj: error: failed to parse YAML input: [[MSG]]
 
 --- !ELF
 FileHeader:
Index: llvm/test/tools/llvm-elfabi/fail-file-write.test
===
--- llvm/test/tools/llvm-elfabi/fail-file-write.test
+++ llvm/test/tools/llvm-elfabi/fail-file-write.test
@@ -5,7 +5,7 @@
 # RUN: mkdir %t.TestDir
 # RUN: touch %t.TestDir/Output.TestFile
 # RUN: chmod 400 %t.TestDir
-# RUN: not llvm-elfabi %s --output-target=elf64-little %t.TestDir/Output.TestFile 2>&1 | FileCheck %s --check-prefix=ERR
+# RUN: not llvm-elfabi %s --output-target=elf64-little %t.TestDir/Output.TestFile 2>&1 | FileCheck -DMSG=%errc_EACCES %s --check-prefix=ERR
 # RUN: chmod 777 %t.TestDir
 # RUN: rm -rf %t.TestDir
 
@@ -15,4 +15,4 @@
 Symbols: {}
 ...
 
-# ERR: {{.*}}Permission denied{{.*}} when trying to open `{{.*}}.TestDir/Output.TestFile` for writing
+# ERR: [[MSG]] when trying to open `{{.*}}.TestDir/Output.TestFile` for writing
Index: llvm/test/tools/llvm-ar/error-opening-permission.test
===
--- llvm/test/tools/llvm-ar/error-opening-permission.test
+++ llvm/test/tools/llvm-ar/error-opening-permission.test
@@ -9,6 +9,6 @@
 # RUN: llvm-ar rc %t/permission.b %t/1.txt
 # RUN: chmod 100 %t/permission.b
 # RUN: not llvm-ar p %t/permission.b 2>&1 | \
-# RUN:   FileCheck %s --check-prefix=NO-PERMISSION -DARCHIVE=%t/permission.b
+# RUN:   FileCheck %s --check-prefix=NO-PERMISSION -DARCHIVE=%t/permission.b -DMSG=%errc_EACCES
 
-# NO-PERMISSION: error: unable to open '[[ARCHIVE]]': {{.*}}{{[pP]}}ermission denied
+# NO-PERMISSION: error: unable to open '[[ARCHIVE]]': [[MSG]]
Index: llvm/docs/TestingGuide.rst
===
--- llvm/docs/TestingGuide.rst
+++ llvm/docs/TestingGuide.rst
@@ -542,7 +542,8 @@
  S

[PATCH] D95808: [test] Use host platform specific error message substitution in lit tests - continued

[James Henderson via Phabricator via cfe-commits]

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

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95808

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

[PATCH] D95776: [OpenCL] Add macro definitions of OpenCL C 3.0 features

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a subscriber: svenvh.
Anastasia added inline comments.



Comment at: clang/lib/Basic/Targets.cpp:743
+  // Assume compiling for FULL profile
+  Builder.defineMacro("__opencl_c_int64");
 }

Btw we could add the other feature macros for earlier versions too but I guess 
it makes code more complicated?



Comment at: clang/lib/Headers/opencl-c.h:17161
+#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200)
+#undef __opencl_c_pipes
+#undef __opencl_c_generic_address_space

Looping in @svenvh  - I don't mind if we define those macros in headers for 
OpenCL 2.0. The only concern is that if we `undef` them here we will end up 
with different behavior between `-finclude-default-header` and 
`-fdeclare-opencl-builtins`. I would suggest not to `undef` them because it is 
better if we have coherency. Alternatively we could also add a third header 
with undefs that can be included at the end for both but it seems to make 
things even more complicated.

FYI `__opencl_c_int64` is already added for all OpenCL versions.



Comment at: clang/test/SemaOpenCL/features.cl:19
+#ifdef PIPES
+ #ifndef __opencl_c_pipes
+  #pragma error "Macro __opencl_c_pipes should be defined"

I think we should test all the macros that are being added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95776

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

[clang] f2b4cc9 - Revert "[test] Default clang/test to FileCheck --allow-unused-prefixes=false"

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2021-02-02T07:38:44-05:00
New Revision: f2b4cc91e0830835c251e0525322effda8522b1c

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

LOG: Revert "[test] Default clang/test to FileCheck 
--allow-unused-prefixes=false"

This reverts commit 80f539526eec31f03aadd96753648686312b1ad1.
Many test failures on mac: http://45.33.8.238/macm1/2772/summary.html
One on win: http://45.33.8.238/win/32442/summary.html

Added: 
clang/test/CodeGen/lit.local.cfg
clang/test/CodeGenCXX/lit.local.cfg
clang/test/Driver/lit.local.cfg

Modified: 
clang/test/Analysis/lit.local.cfg
clang/test/lit.cfg.py

Removed: 
clang/test/OpenMP/lit.local.cfg



diff  --git a/clang/test/Analysis/lit.local.cfg 
b/clang/test/Analysis/lit.local.cfg
index 1e8cf4c3b7c4..1560848b1f75 100644
--- a/clang/test/Analysis/lit.local.cfg
+++ b/clang/test/Analysis/lit.local.cfg
@@ -26,3 +26,9 @@ config.substitutions.append(('%normalize_sarif',
 
 if not config.root.clang_staticanalyzer:
 config.unsupported = True
+
+fc = ToolSubst('FileCheck', unresolved='fatal')
+# Insert this first. Then, we'll first update the blank FileCheck command; 
then,
+# the default substitution of FileCheck will replace it to its full path.
+config.substitutions.insert(0, (fc.regex,
+'FileCheck --allow-unused-prefixes=false'))

diff  --git a/clang/test/CodeGen/lit.local.cfg 
b/clang/test/CodeGen/lit.local.cfg
new file mode 100644
index ..c5bb8b60a52a
--- /dev/null
+++ b/clang/test/CodeGen/lit.local.cfg
@@ -0,0 +1,9 @@
+# -*- Python -*- vim: set ft=python ts=4 sw=4 expandtab tw=79:
+from lit.llvm.subst import ToolSubst
+
+fc = ToolSubst('FileCheck', unresolved='fatal')
+# Insert this first. Then, we'll first update the blank FileCheck command; 
then,
+# the default substitution of FileCheck will replace it to its full path.
+config.substitutions.insert(0, (fc.regex,
+'FileCheck --allow-unused-prefixes=false'))
+

diff  --git a/clang/test/CodeGenCXX/lit.local.cfg 
b/clang/test/CodeGenCXX/lit.local.cfg
new file mode 100644
index ..c5bb8b60a52a
--- /dev/null
+++ b/clang/test/CodeGenCXX/lit.local.cfg
@@ -0,0 +1,9 @@
+# -*- Python -*- vim: set ft=python ts=4 sw=4 expandtab tw=79:
+from lit.llvm.subst import ToolSubst
+
+fc = ToolSubst('FileCheck', unresolved='fatal')
+# Insert this first. Then, we'll first update the blank FileCheck command; 
then,
+# the default substitution of FileCheck will replace it to its full path.
+config.substitutions.insert(0, (fc.regex,
+'FileCheck --allow-unused-prefixes=false'))
+

diff  --git a/clang/test/Driver/lit.local.cfg b/clang/test/Driver/lit.local.cfg
new file mode 100644
index ..7dbadaeed12f
--- /dev/null
+++ b/clang/test/Driver/lit.local.cfg
@@ -0,0 +1,26 @@
+from lit.llvm.subst import ToolSubst
+
+fc = ToolSubst('FileCheck', unresolved='fatal')
+# Insert this first. Then, we'll first update the blank FileCheck command; 
then,
+# the default substitution of FileCheck will replace it to its full path.
+config.substitutions.insert(0, (fc.regex,
+'FileCheck --allow-unused-prefixes=false'))
+
+config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', 
'.F90', '.f95',
+   '.cu', '.rs', '.cl', '.hip']
+config.substitutions = list(config.substitutions)
+config.substitutions.insert(0,
+('%clang_cc1',
+ """*** Do not use 'clang -cc1' in Driver tests. ***""") )
+
+# Remove harmful environmental variables for clang Driver tests.
+# Some might be useful for other tests so they are only removed here.
+driver_overwrite_env_vars = ['MACOSX_DEPLOYMENT_TARGET',
+ 'IPHONEOS_DEPLOYMENT_TARGET',
+ 'SDKROOT', 'CCC_OVERRIDE_OPTIONS',
+ 'CC_PRINT_OPTIONS', 'CC_PRINT_HEADERS',
+ 'CC_LOG_DIAGNOSTICS']
+
+for name in driver_overwrite_env_vars:
+  if name in config.environment:
+del config.environment[name]

diff  --git a/clang/test/OpenMP/lit.local.cfg b/clang/test/OpenMP/lit.local.cfg
deleted file mode 100644
index ac72c2de9777..
--- a/clang/test/OpenMP/lit.local.cfg
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- Python -*- vim: set ft=python ts=4 sw=4 expandtab tw=79:
-from lit.llvm.subst import ToolSubst
-
-fc = ToolSubst('FileCheck', unresolved='fatal')
-# the parent introduced the opposite rule, so we replace it if we see it.
-if len(config.substitutions) > 0 and config.substitutions[0] == (fc.regex, 
'FileCheck --allow-unused-prefixes=false'):
-config.substitutions[0] = (
-fc.regex, 'FileCheck --allow-unused-prefixes=true')
-else:
-config.substitutions.insert(0, (fc.regex, 'FileCheck 
--allow-unused-prefixes=true'))

diff  --git a/clang/test/lit.cfg.py b/clang/test/lit.cfg.py
index a

[PATCH] D95778: [OpenCL] Introduce new language options for OpenCL keywords.

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

> LGTM, but perhaps you can add a test that has each keyword disabled?

FYI we currently already test that `pipe` and `generic` are valid for OpenCL 
2.0 and invalid for OpenCL < 2.0. Or do you mean different kind of tests? In 
OpenCL 3.0 we will have to set the new `LangOpts` fields based on the values of 
`OpenCLOptions`  but my guess is that is going to be added in the subsequent 
patches...




Comment at: clang/include/clang/Basic/LangOptions.def:218
 LANGOPT(OpenCLCPlusPlusVersion , 32, 0, "C++ for OpenCL version")
+LANGOPT(OpenCLGenericKeyword, 1, 0, "OpenCL generic keyword")
+LANGOPT(OpenCLPipeKeyword   , 1, 0, "OpenCL pipe keyword")

Normally we use just a name of the feature, so perhaps:

OpenCLGenericKeyword -> OpenCLGenericAddressSpace
OpenCLPipeKeyword -> OpenCLPipe


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95778

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

[PATCH] D95523: [OpenCL] Add cl_khr_subgroup_ballot to TableGen BIFs

[Anastasia Stulova via Phabricator via cfe-commits]

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

LGTM! Thanks!




Comment at: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl:141
+kernel void extended_subgroup(global uint4 *out) {
+  out[0] = get_sub_group_eq_mask();
+#if __OPENCL_C_VERSION__ < CL_VERSION_2_0 && !defined(__OPENCL_CPP_VERSION__)

svenvh wrote:
> Anastasia wrote:
> > I appreciate we haven't addressed the standard header testing holistically 
> > yet and this functionality was added in `opencl-c.h` without testing the 
> > functions, but would it be better to test each function at least here?
> > 
> > Even though the final goal should be testing all overloads, this is outside 
> > of the scope of this work that is closing the gap between `opencl-c.h` and 
> > this experimental function declaration mechanism.
> > but would it be better to test each function at least here?
> 
> I think that defeats the purpose of this test.  This test is meant to test 
> the basic functionality of `-fdeclare-opencl-builtins`.  It is not a 
> completeness test.
> 
> A completeness test shouldn't be tied to `-fdeclare-opencl-builtins` alone; 
> such a test should also be run against `opencl-c.h`, so this would be the 
> wrong test to turn into a completeness test in my opinion.
Ok, this test does test functionality selectively but I wouldn't be able to 
tell how one selects what to test. Perhaps a comment would help for the future 
development...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95523

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

[PATCH] D95608: [OpenCL][PR48896] Fix address space in binding of initializer lists to references

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia updated this revision to Diff 320751.
Anastasia marked an inline comment as done.
Anastasia added a comment.

Fixed value kind.


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

https://reviews.llvm.org/D95608

Files:
  clang/lib/Sema/SemaInit.cpp
  clang/test/CodeGenOpenCLCXX/addrspace-references.cl
  clang/test/SemaOpenCLCXX/address-space-references.cl

Index: clang/test/SemaOpenCLCXX/address-space-references.cl
===
--- clang/test/SemaOpenCLCXX/address-space-references.cl
+++ clang/test/SemaOpenCLCXX/address-space-references.cl
@@ -10,8 +10,20 @@
 // can't detect this case and therefore fails.
 int bar(const unsigned int &i);
 
+typedef short short2 __attribute__((ext_vector_type(2)));
+class C {
+public:
+  void gen(const short2 &);
+  void glob(__global const short2 &); //expected-note{{passing argument to parameter here}}
+  void nested_list(const short2 (&)[2]);
+};
+
 void foo() {
   bar(1); // expected-error{{binding reference of type 'const __global unsigned int' to value of type 'int' changes address space}}
+  C c;
+  c.gen({1, 2});
+  c.glob({1, 2}); //expected-error{{binding reference of type 'const __global short2' (vector of 2 'short' values) to value of type 'void' changes address space}}
+  c.nested_list({{1, 2}, {3, 4}});
 }
 
 // Test addr space conversion with nested pointers
Index: clang/test/CodeGenOpenCLCXX/addrspace-references.cl
===
--- clang/test/CodeGenOpenCLCXX/addrspace-references.cl
+++ clang/test/CodeGenOpenCLCXX/addrspace-references.cl
@@ -1,8 +1,16 @@
-//RUN: %clang_cc1 %s -cl-std=clc++ -triple spir -emit-llvm -o - | FileCheck %s
+//RUN: %clang_cc1 %s -cl-std=clc++ -triple spir -emit-llvm -o - -O0 | FileCheck %s
+
+typedef short short2 __attribute__((ext_vector_type(2)));
 
 int bar(const unsigned int &i);
-// CHECK-LABEL: define{{.*}} spir_func void @_Z3foov() 
-void foo() {
+
+class C {
+public:
+  void bar(const short2 &);
+};
+
+// CHECK-LABEL: define{{.*}} spir_func void @_Z6scalarv()
+void scalar() {
   // The generic addr space reference parameter object will be bound
   // to a temporary value allocated in private addr space. We need an
   // addrspacecast before passing the value to the function.
@@ -12,3 +20,14 @@
   // CHECK: call spir_func i32 @_Z3barRU3AS4Kj(i32 addrspace(4)* align 4 dereferenceable(4) [[REG]])
   bar(1);
 }
+
+// Test list initialization
+// CHECK-LABEL: define{{.*}} spir_func void @_Z4listv()
+void list() {
+  C c1;
+// CHECK: [[REF:%.*]] = alloca <2 x i16>
+// CHECK: store <2 x i16> , <2 x i16>* [[REF]]
+// CHECK: [[REG:%[.a-z0-9]+]] = addrspacecast <2 x i16>* [[REF]] to <2 x i16> addrspace(4)*
+// CHECK: call {{.*}}void @_ZNU3AS41C3barERU3AS4KDv2_s(%class.C addrspace(4)* {{.*}}, <2 x i16> addrspace(4)*{{.*}} [[REG]])
+  c1.bar({1, 2});
+}
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -4289,17 +4289,37 @@
 if (Sequence.step_begin() != Sequence.step_end())
   Sequence.RewrapReferenceInitList(cv1T1, InitList);
   }
-
+  // Perform address space compatibility check.
+  QualType cv1T1IgnoreAS = cv1T1;
+  if (T1Quals.hasAddressSpace()) {
+Qualifiers T2Quals;
+static_cast(
+S.Context.getUnqualifiedArrayType(InitList->getType(), T2Quals));
+if (!T1Quals.isAddressSpaceSupersetOf(T2Quals)) {
+  Sequence.SetFailed(
+  InitializationSequence::FK_ReferenceInitDropsQualifiers);
+  return;
+}
+// Ignore address space of reference type at this point and perform address
+// space conversion after the reference binding step.
+cv1T1IgnoreAS =
+S.Context.getQualifiedType(T1, T1Quals.withoutAddressSpace());
+  }
   // Not reference-related. Create a temporary and bind to that.
-  InitializedEntity TempEntity = InitializedEntity::InitializeTemporary(cv1T1);
+  InitializedEntity TempEntity =
+  InitializedEntity::InitializeTemporary(cv1T1IgnoreAS);
 
   TryListInitialization(S, TempEntity, Kind, InitList, Sequence,
 TreatUnavailableAsInvalid);
   if (Sequence) {
 if (DestType->isRValueReferenceType() ||
-(T1Quals.hasConst() && !T1Quals.hasVolatile()))
-  Sequence.AddReferenceBindingStep(cv1T1, /*BindingTemporary=*/true);
-else
+(T1Quals.hasConst() && !T1Quals.hasVolatile())) {
+  Sequence.AddReferenceBindingStep(cv1T1IgnoreAS,
+   /*BindingTemporary=*/true);
+  if (T1Quals.hasAddressSpace())
+Sequence.AddQualificationConversionStep(
+cv1T1, DestType->isRValueReferenceType() ? VK_XValue : VK_LValue);
+} else
   Sequence.SetFailed(
   InitializationSequence::FK_NonConstLValueReferenceBindingToTemporary);
   }
___
cfe-commits mailing list
cfe-commi

[PATCH] D95608: [OpenCL][PR48896] Fix address space in binding of initializer lists to references

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added inline comments.



Comment at: clang/lib/Sema/SemaInit.cpp:4308
+  if (T1Quals.hasAddressSpace())
+Sequence.AddQualificationConversionStep(cv1T1, VK_XValue);
+} else

rjmccall wrote:
> Anastasia wrote:
> > rjmccall wrote:
> > > This should only be `VK_XValue` if we're binding a r-value reference, I 
> > > think.
> > Yes, I think so too.
> Did you mean to fix this to conditionally use VK_LValue?
Sure, I have added it now. Sorry I got confused somehow.


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

https://reviews.llvm.org/D95608

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

[PATCH] D95776: [OpenCL] Add macro definitions of OpenCL C 3.0 features

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added inline comments.



Comment at: clang/lib/Headers/opencl-c.h:17161
+#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200)
+#undef __opencl_c_pipes
+#undef __opencl_c_generic_address_space

Anastasia wrote:
> Looping in @svenvh  - I don't mind if we define those macros in headers for 
> OpenCL 2.0. The only concern is that if we `undef` them here we will end up 
> with different behavior between `-finclude-default-header` and 
> `-fdeclare-opencl-builtins`. I would suggest not to `undef` them because it 
> is better if we have coherency. Alternatively we could also add a third 
> header with undefs that can be included at the end for both but it seems to 
> make things even more complicated.
> 
> FYI `__opencl_c_int64` is already added for all OpenCL versions.
> The only concern is that if we undef them here we will end up with different 
> behavior between -finclude-default-header and -fdeclare-opencl-builtins

This is a valid point.  Doing the undefs only in `opencl-c.h` will lead to a 
problem similar to https://reviews.llvm.org/D91429 .

A third header just for the undefs sounds like a bit of an overkill indeed, 
although having duplication isn't great either.  Not sure what's best to be 
honest.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95776

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

[PATCH] D95516: [clang][cli] Benchmark command line round-trip

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 updated this revision to Diff 320755.
jansvoboda11 added a comment.

Add license header


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95516

Files:
  clang/CMakeLists.txt
  clang/benchmarks/CMakeLists.txt
  clang/benchmarks/CompilerInvocationBench.cpp

Index: clang/benchmarks/CompilerInvocationBench.cpp
===
--- /dev/null
+++ clang/benchmarks/CompilerInvocationBench.cpp
@@ -0,0 +1,85 @@
+//===-- CompilerInvocationBench.cpp - Argument parsing benchmark --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/CompilerInvocation.h"
+#include "clang/Frontend/TextDiagnosticBuffer.h"
+
+#include "benchmark/benchmark.h"
+
+using namespace llvm;
+using namespace clang;
+
+// Pointer to '--' in Argv that got replaced by '-round-trip-args'.
+static const char **Begin;
+
+// Pointer to the end of Argv.
+static const char **End;
+
+// Returns a dummy DiagnosticsEngine.
+static DiagnosticsEngine &Diags() {
+  static IntrusiveRefCntPtr Diags =
+  CompilerInstance::createDiagnostics(new DiagnosticOptions,
+  new TextDiagnosticBuffer);
+  return *Diags;
+}
+
+// Parses the command line arguments starting **after** the injected
+// '-round-trip-args', resulting in a parse **without** round-trip.
+static void BM_CompilerInvocationNoRoundTrip(benchmark::State &State) {
+  for (auto _ : State) {
+CompilerInvocation Invocation;
+CompilerInvocation::CreateFromArgs(Invocation, {Begin + 1, End}, Diags());
+  }
+}
+
+// Parses the command line arguments starting **at** the injected
+// '-round-trip-args', resulting in a parse **with** round-trip.
+static void BM_CompilerInvocationDoRoundTrip(benchmark::State &State) {
+  for (auto _ : State) {
+CompilerInvocation Invocation;
+CompilerInvocation::CreateFromArgs(Invocation, {Begin, End}, Diags());
+  }
+}
+
+BENCHMARK(BM_CompilerInvocationNoRoundTrip);
+BENCHMARK(BM_CompilerInvocationDoRoundTrip);
+
+// USAGE:
+// ./CompilerInvocationBench [ Google Benchmark options ... ] \
+//-- [ CompilerInvocation::CreateFromArgs arguments ... ]
+int main(int Argc, const char *Argv[]) {
+  // Find the '--' argument.
+  int DashDashIndex = 0;
+  for (int i = 0; i < Argc; ++i)
+if (StringRef(Argv[i]) == "--")
+  DashDashIndex = i;
+
+  if (DashDashIndex == 0) {
+llvm::errs() << "USAGE:\n"
+ << "  " << Argv[0] << " [ Google Benchmark options ... ] -- "
+ << "[ CompilerInvocation::CreateFromArgs arguments ... ]\n";
+return 1;
+  }
+
+  // Remove all '-round-trip-args' occurrences.
+  for (int i = DashDashIndex + 1; i < Argc; ++i)
+if (StringRef(Argv[i]) == "-round-trip-args")
+  Argv[i] = "";
+
+  // Inject '-round-trip-args' in place of '--'.
+  Argv[DashDashIndex] = "-round-trip-args";
+
+  Begin = Argv + DashDashIndex;
+  End = Argv + Argc;
+
+  int BenchmarkArgc = DashDashIndex - Argc;
+
+  ::benchmark::Initialize(&BenchmarkArgc, const_cast(Argv));
+  ::benchmark::RunSpecifiedBenchmarks();
+}
Index: clang/benchmarks/CMakeLists.txt
===
--- /dev/null
+++ clang/benchmarks/CMakeLists.txt
@@ -0,0 +1,7 @@
+add_benchmark(CompilerInvocationBench CompilerInvocationBench.cpp)
+
+target_link_libraries(CompilerInvocationBench
+  PRIVATE
+  clangFrontend
+  LLVMSupport
+  )
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -879,6 +879,10 @@
   process_llvm_pass_plugins()
 endif()
 
+if (LLVM_INCLUDE_BENCHMARKS)
+  add_subdirectory(benchmarks)
+endif()
+
 configure_file(
   ${CLANG_SOURCE_DIR}/include/clang/Config/config.h.cmake
   ${CLANG_BINARY_DIR}/include/clang/Config/config.h)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

[Alexey Bader via Phabricator via cfe-commits]

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

In D89909#2536157 , @Anastasia wrote:

> In D89909#2534790 , @bader wrote:
>
>>> Regarding SYCLDevice and SYCLAddrSpaceMap I am still not very convinced 
>>> about the flow. Have you had any design discussion regarding this already 
>>> that you could point to?
>>
>> We discussed this with you in https://github.com/intel/llvm/pull/1039/.
>
> I can't see.

The mapping has been discussed in this comment: 
https://github.com/intel/llvm/pull/1039/#discussion_r369667791.

>>> My main concern is that I am not sure it fits with the main design of Clang 
>>> - producing IR that is to be consumed by multiple targets rather than only 
>>> one specific target or even an external tool. Why do you add a triple 
>>> component that is used only for one target SPIR:
>>>
>>> How would existing toolchains that consume LLVM-IR for SPIR cope with the 
>>> fact that the Default address space is different for C++ and SYCL.
>>
>> High level languages differences doesn't matter for toolchains consuming 
>> LLVM IR - it can python, D or SYCL. Toolchains are assuming that LLVM IR 
>> follows the sematic defined in SPIR-1.2 document - 
>> https://www.khronos.org/registry/SPIR/specs/spir_spec-1.2.pdf.
>
> I can't understand what you mean by "doesn't matter"?

LLVM has it's own sematic which toolchains rely on. Toolchains consuming LLVM 
IR doesn't know if this LLVM IR was emitted by C++ compiler or written manually 
- they can rely only on LLVM IR semantic defined by 
https://llvm.org/docs/LangRef.html.

> If you compiler from C++ you get one address space as `Default` and if you 
> compile from SYCL you get a different one for the same target - how do you 
> expect the toolchain consuming the IR to handle that?

Technically clang changes SPIR target mapping for Default address space only 
for `sycldevice` environment component of the target triple, so it doesn't 
depend on the input language i.e. Default is mapped to the same LLVM address 
space for C++ and SYCL.

> FYI, the document is no longer describing the current SPIR target adequately 
> as implementation deviated quite a bit from the original documentation.

This is unfortunate. Do you know if there are any plans to provide up-to-date 
documentation? It's critical for non-clang front-ends targeting SPIR-V format.

>>> Why is changing of `the address space map necessary for SPIR but not the 
>>> other targets?
>>
>> The main reason is the difference in handling Default address space in C++ 
>> for OpenCL mode and SYCL. C++ for OpenCL doesn't always deduce address space 
>> and there are cases when Default is used and SPIR target maps it AS 0 
>> (equivalent of SPIR-V Function storage class). This lead to inconsistencies 
>> like reported here: https://bugs.llvm.org/show_bug.cgi?id=45472.
>>
>> SYCL doesn't deduce language address space at all relies on mapping Default 
>> in LLVM AS equivalent of SPIR-V generic.
>>
>> NOTE: other GPU targets like AMDGPU and NVPTX do the same i.e. maps Default 
>> language AS to LLVM IR AS equivalent of SPIR-V generic, so there is no need 
>> to update. I believe SPIR target must apply the same mapping.
>
> Generic address space in Clang is a logical concept added for OpenCL to 
> implement the following logical concept .
> https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#the-generic-address-space
>
> Targets are allowed to map it to any physical address space (it is very 
> reasonable to map it to `Default`) but it is only used for restricted use 
> cases i.e. pointers or references.

I agree with that, but I don't get how it's related to the mapping language AS 
to LLVM AS.

> `Default` address space is where objects are put by default - for example in 
> C++ everything is mapped to this address space. I don't see why you just 
> replace `Default` by OpenCL generic. It has been added for a very different 
> purpose.

SPIR-V Generic is the only address space allowing us to preserve correct 
semantic of the program (possibly `global` can be used, but we didn't 
investigate this option due to obvious performance implications). The objects 
from `Default` AS might be allocated in any physical AS, so LLVM IR AS 4 allows 
LLVM compiler to infer it using `InferAddressSpace` pass.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89909

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

[PATCH] D76802: [InstrProfiling] Use !associated metadata for counters, data and values

[Tom Weaver via Phabricator via cfe-commits]

TWeaver added a comment.

Hiya,

this patch (probably) broke the build bot at:

http://lab.llvm.org:8011/#/builders/53/builds/1184


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76802

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

[PATCH] D95735: [ASTMatchers] Fix matching after generic top-level matcher

[Aaron Ballman via Phabricator via cfe-commits]

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

In D95735#2534715 , @steveire wrote:

> In D95735#2534400 , @aaron.ballman 
> wrote:
>
>> I'm a bit confused -- I only get one match when I try out your example: 
>> https://godbolt.org/z/xn9efY Are there other changes in-flight that 
>> necessitate this, or is something else going on?
>
> Yes, only `IgnoreUnlessSpelledInSource` mode is affected: 
> https://godbolt.org/z/ffareK

Ahhh, of course, thank you! LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95735

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

[PATCH] D95740: [ASTMatchers] Ignore parts of BindingDecls which are not spelled in source

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!




Comment at: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:2607
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }

steveire wrote:
> aaron.ballman wrote:
> > Can you help me to better understand the proposed change? I find this to be 
> > surprising behavior -- the thing the user wrote in the source are the 
> > binding declarations, the hidden thing they didn't write in the source was 
> > the decomposition declaration. e.g., the user introduced some names `f`, 
> > `s`, and `t` in the declaration so I would imagine that these *are* spelled 
> > in source. What I don't think is necessarily spelled in source is the 
> > decomposition declaration for the `int[3]` to bind to. So I was expecting 
> > this to be `EXPECT_TRUE` instead of `EXPECT_FALSE`.
> > Can you help me to better understand the proposed change? I find this to be 
> > surprising behavior -- the thing the user wrote in the source are the 
> > binding declarations, the hidden thing they didn't write in the source was 
> > the decomposition declaration. e.g., the user introduced some names `f`, 
> > `s`, and `t` in the declaration so I would imagine that these *are* spelled 
> > in source. What I don't think is necessarily spelled in source is the 
> > decomposition declaration for the `int[3]` to bind to. 
> 
> Indeed. The `bindingDecl` matches, but the `has(expr())` part does not, after 
> this change: https://godbolt.org/z/Mqb9Mx
> 
> 
The test changes nicely clarify what's going on, thank you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95740

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

[clang] d6a0636 - [ASTMatchers] Fix matching after generic top-level matcher

[Stephen Kelly via cfe-commits]

Author: Stephen Kelly
Date: 2021-02-02T13:31:05Z
New Revision: d6a06365cf12bebe20a7d65cf3894608efc089b4

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

LOG: [ASTMatchers] Fix matching after generic top-level matcher

With a matcher like

  expr(anyOf(integerLiteral(equals(42)), unless(expr(

and code such as

  struct B {
B(int);
  };

  B func1() { return 42; }

the top-level expr() would match each of the nodes which are not spelled
in the source and then ignore-traverse to match the integerLiteral node.
This would result in multiple results reported for the integerLiteral.

Fix that by only running matching logic on nodes which are not skipped
with the top-level matcher.

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

Added: 


Modified: 
clang/lib/ASTMatchers/ASTMatchFinder.cpp
clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Removed: 




diff  --git a/clang/lib/ASTMatchers/ASTMatchFinder.cpp 
b/clang/lib/ASTMatchers/ASTMatchFinder.cpp
index 41be3738e707..69957a952d17 100644
--- a/clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ b/clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -837,6 +837,14 @@ class MatchASTVisitor : public 
RecursiveASTVisitor,
   if (EnableCheckProfiling)
 Timer.setBucket(&TimeByBucket[MP.second->getID()]);
   BoundNodesTreeBuilder Builder;
+
+  {
+TraversalKindScope RAII(getASTContext(), MP.first.getTraversalKind());
+if (getASTContext().getParentMapContext().traverseIgnored(DynNode) !=
+DynNode)
+  continue;
+  }
+
   if (MP.first.matches(DynNode, this, &Builder)) {
 MatchVisitor Visitor(ActiveASTContext, MP.second);
 Builder.visitMatches(&Visitor);

diff  --git a/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp 
b/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
index c67c40ed960a..06c2bbc29e5c 100644
--- a/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ b/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2519,6 +2519,78 @@ template<> bool timesTwo(bool){
 EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
 EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
   }
+
+  Code = R"cpp(
+struct B {
+  B(int);
+};
+
+B func1() { return 42; }
+  )cpp";
+  {
+auto M = expr(ignoringImplicit(integerLiteral(equals(42)).bind("intLit")));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("intLit", 1)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("intLit", 1)));
+  }
+  {
+auto M = expr(unless(integerLiteral(equals(24.bind("intLit");
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("intLit", 7)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("intLit", 1)));
+  }
+  {
+auto M =
+expr(anyOf(integerLiteral(equals(42)).bind("intLit"), unless(expr(;
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("intLit", 1)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("intLit", 1)));
+  }
+  {
+auto M = expr(allOf(integerLiteral(equals(42)).bind("intLit"), expr()));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("intLit", 1)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("intLit", 1)));
+  }
+  {
+auto M = expr(integerLiteral(equals(42)).bind("intLit"), expr());
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("intLit", 1)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("intLit", 1)));
+  }
+  {
+auto M = expr(optionally(integerLiteral(equals(42)).bind("intLit")));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("intLit", 1)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("intLit", 1)));
+  }
+  {
+auto M = expr().bind("allExprs");
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("allExprs", 7)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("allExprs", 1)));
+  }
 }
 
 TEST(Trave

[PATCH] D95735: [ASTMatchers] Fix matching after generic top-level matcher

[Stephen Kelly 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 rGd6a06365cf12: [ASTMatchers] Fix matching after generic 
top-level matcher (authored by stephenkelly).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95735

Files:
  clang/lib/ASTMatchers/ASTMatchFinder.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2519,6 +2519,78 @@
 EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
 EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
   }
+
+  Code = R"cpp(
+struct B {
+  B(int);
+};
+
+B func1() { return 42; }
+  )cpp";
+  {
+auto M = expr(ignoringImplicit(integerLiteral(equals(42)).bind("intLit")));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("intLit", 1)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("intLit", 1)));
+  }
+  {
+auto M = expr(unless(integerLiteral(equals(24.bind("intLit");
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("intLit", 7)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("intLit", 1)));
+  }
+  {
+auto M =
+expr(anyOf(integerLiteral(equals(42)).bind("intLit"), unless(expr(;
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("intLit", 1)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("intLit", 1)));
+  }
+  {
+auto M = expr(allOf(integerLiteral(equals(42)).bind("intLit"), expr()));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("intLit", 1)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("intLit", 1)));
+  }
+  {
+auto M = expr(integerLiteral(equals(42)).bind("intLit"), expr());
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("intLit", 1)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("intLit", 1)));
+  }
+  {
+auto M = expr(optionally(integerLiteral(equals(42)).bind("intLit")));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("intLit", 1)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("intLit", 1)));
+  }
+  {
+auto M = expr().bind("allExprs");
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_AsIs, M),
+std::make_unique>("allExprs", 7)));
+EXPECT_TRUE(matchAndVerifyResultTrue(
+Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+std::make_unique>("allExprs", 1)));
+  }
 }
 
 TEST(Traversal, traverseNoImplicit) {
Index: clang/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -837,6 +837,14 @@
   if (EnableCheckProfiling)
 Timer.setBucket(&TimeByBucket[MP.second->getID()]);
   BoundNodesTreeBuilder Builder;
+
+  {
+TraversalKindScope RAII(getASTContext(), MP.first.getTraversalKind());
+if (getASTContext().getParentMapContext().traverseIgnored(DynNode) !=
+DynNode)
+  continue;
+  }
+
   if (MP.first.matches(DynNode, this, &Builder)) {
 MatchVisitor Visitor(ActiveASTContext, MP.second);
 Builder.visitMatches(&Visitor);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93844: [clang-format] Add possibility to be based on parent directory

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

As a follow up it may be wise to pass a diag handler to parseConfiguration as 
when we parse it a second time, we probably want to disregard any warnings 
(like unknown key) detected as they will have been printed on the first pass.




Comment at: clang/lib/Format/Format.cpp:3011-3017
+  std::for_each(
+  ChildFormatTextToApply.rbegin(), ChildFormatTextToApply.rend(),
+  [&Style, AllowUnknownOptions](const auto &Ptr) {
+auto Ec = parseConfiguration(*Ptr, &Style, 
AllowUnknownOptions);
+// It was already correctly parsed.
+assert(!Ec);
+  });

Nit: just use a for loop over a lambda.



Comment at: clang/lib/Format/Format.cpp:3051
+// It was already correctly parsed.
+assert(!Ec);
+  }

Nit: Add a void cast to silence unused warnings in release builds.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93844

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

[PATCH] D95739: [ASTMatchers] Add matchers for decomposition decls

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95739

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

[PATCH] D94955: [clang-format] Treat ForEachMacros as loops

[Jiashu Zou via Phabricator via cfe-commits]

GoBigorGoHome added a comment.

@MyDeveloperDay 
I changed the `verifyFormat` to `EXPECT_NE` because I don't know the proper way 
"to show that the previous tests were wrong", and I agree with you that it is a 
dirty hack. However, I think it is already clear why the tests were changed, 
that was because the short (empty) block followed an ForEachMacro was not 
wrapped previously and that is the very thing this patch wants to change.

Another thing that need to be clarified is that it seems that the rule 
`AllowShortLoopsOnASingleLine` only controls the case where the loop body is 
not enclosed in braces, e.g. `for (int i = 0; i < 10; i++) std::cout << i;`  
but not `for (int i = 0; i < 10; i++) { std::cout << i;}` so that 
`AllowShortLoopsOnASingleLine` is orthogonal to 
`AllowShortBlocksOnAsingleLine`. Can you confirm this?

In summary, (i) I am confused and need help in how to minimise the test changes 
for the purpose of this patch, and (ii) I agree that more tests are needed to 
prove that nothing has been broken.

In D94955#2536094 , @MyDeveloperDay 
wrote:

> I'm never going to be the one to accept patches where people change tests 
> without making it really clear why they are changing it. You have to prove 
> you are not regressing behaviour, I work on the Beyonce rule, "if you liked 
> it you should have put a test on it"
>
> That means if you are changing that rule you are breaking what someone else 
> did, so you have to work doubly hard to a) minimise the test changes and b) 
> prove you haven't broken anything.
>
> I'm always suspicious why people change a `verifyFormat` to an `EXPECT_EQ` to 
> me it smells as if you tried it with verifyFormat and it didn't work so 
> hacked a way around it.. ultimately this tends to leads to a bug further down 
> the road.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94955

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

[PATCH] D95846: [analyzer] Updated comments to reflect D85817

[Valeriy Savchenko via Phabricator via cfe-commits]

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

Thanks for doing that!
I have a minor nit-picking comment, it is preferable to use present-tense 
imperative-style commit messages, i.e. "Update comment...".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95846

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

[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

[Alexey Bader via Phabricator via cfe-commits]

bader updated this revision to Diff 320761.
bader added a comment.

Fixed a couple of typos in the comments; NFC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89909

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Sema/ParsedAttr.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGenSYCL/address-space-cond-op.cpp
  clang/test/CodeGenSYCL/address-space-of-returns.cpp
  clang/test/CodeGenSYCL/address-space-parameter-conversions.cpp
  clang/test/CodeGenSYCL/address-spaces-struct.cpp
  clang/test/CodeGenSYCL/address-spaces.cpp
  clang/test/SemaSYCL/address-space-parameter-conversions.cpp
  clang/test/SemaTemplate/address_space-dependent.cpp
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/Support/Triple.cpp

Index: llvm/lib/Support/Triple.cpp
===
--- llvm/lib/Support/Triple.cpp
+++ llvm/lib/Support/Triple.cpp
@@ -247,6 +247,8 @@
   case Musl: return "musl";
   case MuslEABI: return "musleabi";
   case MuslEABIHF: return "musleabihf";
+  case SYCLDevice:
+return "sycldevice";
   case Simulator: return "simulator";
   }
 
@@ -554,6 +556,7 @@
   .StartsWith("itanium", Triple::Itanium)
   .StartsWith("cygnus", Triple::Cygnus)
   .StartsWith("coreclr", Triple::CoreCLR)
+  .StartsWith("sycldevice", Triple::SYCLDevice)
   .StartsWith("simulator", Triple::Simulator)
   .StartsWith("macabi", Triple::MacABI)
   .Default(Triple::UnknownEnvironment);
Index: llvm/include/llvm/ADT/Triple.h
===
--- llvm/include/llvm/ADT/Triple.h
+++ llvm/include/llvm/ADT/Triple.h
@@ -222,8 +222,9 @@
 Itanium,
 Cygnus,
 CoreCLR,
+SYCLDevice,
 Simulator, // Simulator variants of other systems, e.g., Apple's iOS
-MacABI, // Mac Catalyst variant of Apple's iOS deployment target.
+MacABI,// Mac Catalyst variant of Apple's iOS deployment target.
 LastEnvironmentType = MacABI
   };
   enum ObjectFormatType {
@@ -497,6 +498,10 @@
isMacCatalystEnvironment()));
   }
 
+  bool isSYCLDeviceEnvironment() const {
+return getEnvironment() == Triple::SYCLDevice;
+  }
+
   bool isOSNetBSD() const {
 return getOS() == Triple::NetBSD;
   }
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 (8388593)}}
+  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388590)}}
 }
 
 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<0x71>();
+  correct<0x7FFFED>();
   tooBig<8388650>(); // expected-note {{in instantiation of function template specialization 'tooBig<8388650>' requested here}}
 
   __attribute__((address_space(1))) char *x;
Index: clang/test/SemaSYCL/address-space-parameter-conversions.cpp
===
--- /dev/null
+++ clang/test/SemaSYCL/address-space-parameter-conversions.cpp
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -fsycl -fsycl-is-device -verify -fsyntax-only -x c++ %s
+
+void bar(int &Data) {}
+void bar2(int &Data) {}
+void bar(__attribute__((opencl_private)) int &Data) {}
+void foo(int *Data) {}
+void foo2(int *Data) {}
+void foo(__attribute__((opencl_private)) int *Data) {}
+
+template 
+void tmpl(T *t) {}
+
+void usages() {
+  __attribute__((opencl_global)) int *GLOB;
+  __attribute__((opencl_private)) int *PRIV;
+  __attribute__((opencl_local)) int *LOC;
+  int *NoAS;
+
+  bar(*GLOB);
+  bar2(*GLOB);
+
+  bar(*PRIV);
+  bar2(*PRIV);
+
+  bar(*NoAS);
+  bar2(*NoAS);
+
+  bar(*LOC);
+  bar2(*LOC);
+
+  foo(GLOB);
+  foo2(GLOB);
+  foo(PRIV);
+  foo2(PRIV);
+  foo(NoAS);
+  foo2(NoAS);
+  foo(LOC);
+  foo2(LOC);
+
+  tmpl(GLOB);
+  tmpl(PRIV);
+  tmpl(NoAS);
+  tmpl(LOC);
+
+  (void)static_cast(GLOB);
+  (void)static_cast(GLOB);
+  // FIXME: determine if we can warn on the below conversions.
+  int *i = GLOB;
+  void *v = 

[PATCH] D94880: Add clang-query support for mapAnyOf

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

I think there should be some documentation change for the new `with` 
functionality.




Comment at: clang/lib/ASTMatchers/Dynamic/Marshallers.h:398-407
+  bool isBuilderMatcher() const override { return false; }
+
+  std::unique_ptr
+  buildMatcherCtor(SourceRange, ArrayRef,
+   Diagnostics *) const override {
+return {};
+  }

Rather than repeat these degenerate definitions six times, should this just be 
the default implementation within `MatcherDescriptor` (so derived classes are 
not required to override them)? Alternatively, should we make a 
`NonBuilderMatcherDescriptor` class that holds the degenerate definition, and 
these derived classes can inherit from `NonBuilderMatcherDescriptor` instead?



Comment at: clang/lib/ASTMatchers/Dynamic/Marshallers.h:1094
+
+  void getArgKinds(ASTNodeKind ThisKind, unsigned ArgNo,
+   std::vector &ArgKinds) const override {





Comment at: clang/lib/ASTMatchers/Dynamic/Parser.cpp:373
+  Tokenizer->consumeNextToken(); // Consume the period.
+  const TokenInfo ChainCallToken = Tokenizer->consumeNextToken();
+  if (ChainCallToken.Kind == TokenInfo::TK_CodeCompletion) {





Comment at: clang/lib/ASTMatchers/Dynamic/Parser.cpp:449
 bool Parser::parseBindID(std::string &BindID) {
-  // Parse .bind("foo")
-  assert(Tokenizer->peekNextToken().Kind == TokenInfo::TK_Period);
-  Tokenizer->consumeNextToken(); // consume the period.
-  const TokenInfo BindToken = Tokenizer->consumeNextToken();
-  if (BindToken.Kind == TokenInfo::TK_CodeCompletion) {
-addCompletion(BindToken, MatcherCompletion("bind(\"", "bind", 1));
-return false;
-  }
-
+  // Parse argument to .bind("foo")
   const TokenInfo OpenToken = Tokenizer->consumeNextToken();





Comment at: clang/lib/ASTMatchers/Dynamic/Parser.cpp:606
+
+  const TokenInfo WithOpenToken = Tokenizer->consumeNextToken();
+




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94880

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

[PATCH] D95846: [analyzer] Updated comments to reflect D85817

[Deep Majumder via Phabricator via cfe-commits]

RedDocMD added a comment.

In D95846#2536380 , @vsavchenko wrote:

> Thanks for doing that!
> I have a minor nit-picking comment, it is preferable to use present-tense 
> imperative-style commit messages, i.e. "Update comment...".

Noted. I will do that in future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95846

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

[PATCH] D76342: [OpenMP] Implement '#pragma omp tile'

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

In D76342#2535321 , @Meinersbur wrote:

> Thank you for the update.
>
> From comparing the diffs, here is the list of main changes I found:
>
> 1. Create `OMPLoopBasedDirective` as a new base class for OMPLoopDirective 
> (and OMPTileDirective) for CollapsedNum and some utility methods for 
> analyzing the CapturedStmt/ForStmt structure (replacing 
> getTopmostAssociatedStructuredBlock, collectAssociatedLoops)
> 2. Add PreInits child to OMPTileDirective (instead of wrapping them in a 
> CompoundStmt of the transformed body/collectAssociatedLoops)
> 3. Use meaningful SourceLocations instead of my placeholder `{}`
> 4. New OMPTransformDirectiveScopeRAII
>   1. to collect nested PreInits (instead by collectAssociatedLoops)
>   2. to assign values to CapturedDecls (instead of adding a `Capturing` 
> argument to various function)
> 5. no call to checkOpenMPLoop for the entire lop nest (but still once per 
> loop)
>
> My remarks to these changes:
>
> 1. Saves us to store all the loop-specific subexpressions in the AST node. 
> However, they are still computed in ActOnOpenMPTileDirective. With the 
> OpenMPIRBuilder (D94973 ) these will also 
> not be necessary for other loop-associated statements.
> 2. looks more consistent with other directives
> 3. This was just laziness on my size. Thank you.
> 4. is what I just did not know. 4.b. still feels like a hack because there 
> are captures variables outside of any CapturedStmt and therefore complicated 
> the AST. Comparable directive such as `master` don't do this.
> 5. The additional call on the entire loop nest felt necessary to check 
> constraints such as invariant loop bounds and disallow nesting. However, both 
> properties are still checked now.

Just one thing. Preinits does not directly relate to CapturedStmt, you can 
consider it as a temp way to optimize the codegen. Also, it allows to support 
the use of data members as loop counters in classes/structures.




Comment at: clang/include/clang/AST/StmtOpenMP.h:448
+  /// Number of collapsed loops as specified by 'collapse' clause.
+  unsigned CollapsedNum = 0;
+

Meinersbur wrote:
> Inaccurate for the tile directive.
We can rename it to something like `NumAssociatedLoops`



Comment at: clang/include/clang/AST/StmtOpenMP.h:651-677
+  static bool
+  doForAllLoops(Stmt *CurStmt, bool TryImperfectlyNestedLoops,
+unsigned NumLoops,
+llvm::function_ref Callback);
+  static bool
+  doForAllLoops(const Stmt *CurStmt, bool TryImperfectlyNestedLoops,
+unsigned NumLoops,

Meinersbur wrote:
> Please add doxygen comments.
> 
> IMHO, using callbacks makes the callers significantly more complicated. Why 
> not fill a SmallVectorImpl with the result?
It just hides all internal representation in the class and the user/caller 
should not worry about proper implementation of the loops processing. Consider 
it as a way to encapsulate representation details.



Comment at: clang/include/clang/AST/StmtOpenMP.h:659
+llvm::function_ref Callback) {
+auto &&NewCallback = [Callback](unsigned Cnt, Stmt *CurStmt) {
+  return Callback(Cnt, CurStmt);

Meinersbur wrote:
> I do not see why making this a forwarding reference.
There is a type mismatch in callback types, `Stmt *` and `const Stmt *`



Comment at: clang/include/clang/AST/StmtOpenMP.h:680-709
+return T->getStmtClass() == OMPSimdDirectiveClass ||
+   T->getStmtClass() == OMPForDirectiveClass ||
+   T->getStmtClass() == OMPTileDirectiveClass ||
+   T->getStmtClass() == OMPForSimdDirectiveClass ||
+   T->getStmtClass() == OMPParallelForDirectiveClass ||
+   T->getStmtClass() == OMPParallelForSimdDirectiveClass ||
+   T->getStmtClass() == OMPTaskLoopDirectiveClass ||

Meinersbur wrote:
> Use `isOpenMPLoopDirective()` instead?
I'll check if it can be used instead, though I just want to be consistent with 
what we have for other statements/expressions/directives.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76342

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

[PATCH] D95739: [ASTMatchers] Add matchers for decomposition decls

[Stephen Kelly 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 rG467a04560143: [ASTMatchers] Add matchers for decomposition 
decls (authored by stephenkelly).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95739

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/lib/ASTMatchers/Dynamic/Registry.cpp
  clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
@@ -2129,6 +2129,37 @@
   EXPECT_TRUE(matchesObjC(ObjCString, objcFinallyStmt()));
 }
 
+TEST(ASTMatchersTest, DecompositionDecl) {
+  StringRef Code = R"cpp(
+void foo()
+{
+int arr[3];
+auto &[f, s, t] = arr;
+
+f = 42;
+}
+  )cpp";
+  EXPECT_TRUE(matchesConditionally(
+  Code, decompositionDecl(hasBinding(0, bindingDecl(hasName("f", true,
+  {"-std=c++17"}));
+  EXPECT_FALSE(matchesConditionally(
+  Code, decompositionDecl(hasBinding(42, bindingDecl(hasName("f", true,
+  {"-std=c++17"}));
+  EXPECT_FALSE(matchesConditionally(
+  Code, decompositionDecl(hasBinding(0, bindingDecl(hasName("s", true,
+  {"-std=c++17"}));
+  EXPECT_TRUE(matchesConditionally(
+  Code, decompositionDecl(hasBinding(1, bindingDecl(hasName("s", true,
+  {"-std=c++17"}));
+
+  EXPECT_TRUE(matchesConditionally(
+  Code,
+  bindingDecl(decl().bind("self"), hasName("f"),
+  forDecomposition(decompositionDecl(
+  hasAnyBinding(bindingDecl(equalsBoundNode("self")),
+  true, {"-std=c++17"}));
+}
+
 TEST(ASTMatchersTestObjC, ObjCAutoreleasePoolStmt) {
   StringRef ObjCString = "void f() {"
  "@autoreleasepool {"
Index: clang/lib/ASTMatchers/Dynamic/Registry.cpp
===
--- clang/lib/ASTMatchers/Dynamic/Registry.cpp
+++ clang/lib/ASTMatchers/Dynamic/Registry.cpp
@@ -144,6 +144,7 @@
   REGISTER_MATCHER(binaryConditionalOperator);
   REGISTER_MATCHER(binaryOperator);
   REGISTER_MATCHER(binaryOperation);
+  REGISTER_MATCHER(bindingDecl);
   REGISTER_MATCHER(blockDecl);
   REGISTER_MATCHER(blockExpr);
   REGISTER_MATCHER(blockPointerType);
@@ -226,6 +227,7 @@
   REGISTER_MATCHER(exprWithCleanups);
   REGISTER_MATCHER(fieldDecl);
   REGISTER_MATCHER(floatLiteral);
+  REGISTER_MATCHER(forDecomposition);
   REGISTER_MATCHER(forEach);
   REGISTER_MATCHER(forEachArgumentWithParam);
   REGISTER_MATCHER(forEachArgumentWithParamType);
@@ -248,6 +250,7 @@
   REGISTER_MATCHER(hasAncestor);
   REGISTER_MATCHER(hasAnyArgument);
   REGISTER_MATCHER(hasAnyBase);
+  REGISTER_MATCHER(hasAnyBinding);
   REGISTER_MATCHER(hasAnyClause);
   REGISTER_MATCHER(hasAnyConstructorInitializer);
   REGISTER_MATCHER(hasAnyDeclaration);
@@ -266,6 +269,7 @@
   REGISTER_MATCHER(hasAttr);
   REGISTER_MATCHER(hasAutomaticStorageDuration);
   REGISTER_MATCHER(hasBase);
+  REGISTER_MATCHER(hasBinding);
   REGISTER_MATCHER(hasBitWidth);
   REGISTER_MATCHER(hasBody);
   REGISTER_MATCHER(hasCanonicalType);
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -347,6 +347,16 @@
 extern const internal::VariadicDynCastAllOfMatcher
 decompositionDecl;
 
+/// Matches binding declarations
+/// Example matches \c foo and \c bar
+/// (matcher = bindingDecl()
+///
+/// \code
+///   auto [foo, bar] = std::make_pair{42, 42};
+/// \endcode
+extern const internal::VariadicDynCastAllOfMatcher
+bindingDecl;
+
 /// Matches a declaration of a linkage specification.
 ///
 /// Given
@@ -7379,6 +7389,80 @@
 Expr::NPC_ValueDependentIsNull);
 }
 
+/// Matches the DecompositionDecl the binding belongs to.
+///
+/// For example, in:
+/// \code
+/// void foo()
+/// {
+/// int arr[3];
+/// auto &[f, s, t] = arr;
+///
+/// f = 42;
+/// }
+/// \endcode
+/// The matcher:
+/// \code
+///   bindingDecl(hasName("f"),
+/// forDecomposition(decompositionDecl())
+/// \endcode
+/// matches 'f' in 'auto &[f, s, t]'.
+AST_MATCHER_P(BindingDecl, forDecomposition, internal::Matcher,
+  InnerMatcher) {
+  if (const ValueDecl *VD = Node.getDecomposedDecl())
+return InnerMatcher.matches(*VD, Finder, Builder);
+  return false;
+}
+
+/// Matches the Nth binding of a DecompositionDecl.
+///
+/// For example, in:
+/// \code
+/// void foo()
+/// {
+/// int arr[3];
+/// auto &[f, s, t] = arr;
+///
+/// f = 42;
+/// }
+/// \endcode
+/// The matcher:
+/// \code
+///   de

[clang] 467a045 - [ASTMatchers] Add matchers for decomposition decls

[Stephen Kelly via cfe-commits]

Author: Stephen Kelly
Date: 2021-02-02T14:11:02Z
New Revision: 467a045601430c81e1a7f41f6a134e751f17df55

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

LOG: [ASTMatchers] Add matchers for decomposition decls

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

Added: 


Modified: 
clang/docs/LibASTMatchersReference.html
clang/include/clang/ASTMatchers/ASTMatchers.h
clang/lib/ASTMatchers/Dynamic/Registry.cpp
clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp

Removed: 




diff  --git a/clang/docs/LibASTMatchersReference.html 
b/clang/docs/LibASTMatchersReference.html
index aac02bc4effe..ac816d28970b 100644
--- a/clang/docs/LibASTMatchersReference.html
+++ b/clang/docs/LibASTMatchersReference.html
@@ -591,6 +591,15 @@ Node Matchers
 
 
 
+MatcherDecl>bindingDeclMatcherBindingDecl>...
+Matches binding 
declarations
+Example matches foo and bar
+(matcher = bindingDecl()
+
+  auto [foo, bar] = std::make_pair{42, 42};
+
+
+
 MatcherDecl>blockDeclMatcherBlockDecl>...
 Matches block 
declarations.
 
@@ -6011,6 +6020,24 @@ AST Traversal Matchers
 
 
 
+MatcherBindingDecl>forDecompositionMatcherValueDecl>
 InnerMatcher
+Matches the 
DecompositionDecl the binding belongs to.
+
+For example, in:
+void foo()
+{
+int arr[3];
+auto &[f, s, t] = arr;
+
+f = 42;
+}
+The matcher:
+  bindingDecl(hasName("f"),
+forDecomposition(decompositionDecl())
+matches 'f' in 'auto &[f, s, t]'.
+
+
+
 MatcherBlockDecl>hasAnyParameterMatcherParmVarDecl>
 InnerMatcher
 Matches any 
parameter of a function or an ObjC method declaration or a
 block.
@@ -7090,6 +7117,40 @@ AST Traversal Matchers
 
 
 
+MatcherDecompositionDecl>hasAnyBindingMatcherBindingDecl>
 InnerMatcher
+Matches any binding 
of a DecompositionDecl.
+
+For example, in:
+void foo()
+{
+int arr[3];
+auto &[f, s, t] = arr;
+
+f = 42;
+}
+The matcher:
+  decompositionDecl(hasAnyBinding(bindingDecl(hasName("f").bind("fBinding"
+matches the decomposition decl with 'f' bound to "fBinding".
+
+
+
+MatcherDecompositionDecl>hasBindingunsigned N, MatcherBindingDecl>
 InnerMatcher
+Matches the Nth binding 
of a DecompositionDecl.
+
+For example, in:
+void foo()
+{
+int arr[3];
+auto &[f, s, t] = arr;
+
+f = 42;
+}
+The matcher:
+  decompositionDecl(hasBinding(0, bindingDecl(hasName("f").bind("fBinding"
+matches the decomposition decl with 'f' bound to "fBinding".
+
+
+
 MatcherDoStmt>hasBodyMatcherStmt> 
InnerMatcher
 
 

diff  --git a/clang/include/clang/ASTMatchers/ASTMatchers.h 
b/clang/include/clang/ASTMatchers/ASTMatchers.h
index cbce6d7d0439..6cd4d26768b5 100644
--- a/clang/include/clang/ASTMatchers/ASTMatchers.h
+++ b/clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -347,6 +347,16 @@ extern const internal::VariadicAllOfMatcher decl;
 extern const internal::VariadicDynCastAllOfMatcher
 decompositionDecl;
 
+/// Matches binding declarations
+/// Example matches \c foo and \c bar
+/// (matcher = bindingDecl()
+///
+/// \code
+///   auto [foo, bar] = std::make_pair{42, 42};
+/// \endcode
+extern const internal::VariadicDynCastAllOfMatcher
+bindingDecl;
+
 /// Matches a declaration of a linkage specification.
 ///
 /// Given
@@ -7379,6 +7389,80 @@ AST_MATCHER(Expr, nullPointerConstant) {
 Expr::NPC_ValueDependentIsNull);
 }
 
+/// Matches the DecompositionDecl the binding belongs to.
+///
+/// For example, in:
+/// \code
+/// void foo()
+/// {
+/// int arr[3];
+/// auto &[f, s, t] = arr;
+///
+/// f = 42;
+/// }
+/// \endcode
+/// The matcher:
+/// \code
+///   bindingDecl(hasName("f"),
+/// forDecomposition(decompositionDecl())
+/// \endcode
+/// matches 'f' in 'auto &[f, s, t]'.
+AST_MATCHER_P(BindingDecl, forDecomposition, internal::Matcher,
+  InnerMatcher) {
+  if (const ValueDecl *VD = Node.getDecomposedDecl())
+   

[PATCH] D95017: [clang-format] Add case aware include sorting.

[Marek Kurdej 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 rGa8105b3766e4: [clang-format] Add case aware include sorting. 
(authored by kentsommer, committed by curdeius).

Changed prior to commit:
  https://reviews.llvm.org/D95017?vs=320007&id=320771#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95017

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/tools/clang-format/ClangFormat.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/SortImportsTestJava.cpp
  clang/unittests/Format/SortIncludesTest.cpp

Index: clang/unittests/Format/SortIncludesTest.cpp
===
--- clang/unittests/Format/SortIncludesTest.cpp
+++ clang/unittests/Format/SortIncludesTest.cpp
@@ -269,7 +269,7 @@
 }
 
 TEST_F(SortIncludesTest, IncludeSortingCanBeDisabled) {
-  FmtStyle.SortIncludes = false;
+  FmtStyle.SortIncludes = FormatStyle::SI_Never;
   EXPECT_EQ("#include \"a.h\"\n"
 "#include \"c.h\"\n"
 "#include \"b.h\"\n",
@@ -598,6 +598,49 @@
  "a.cc"));
 }
 
+TEST_F(SortIncludesTest, SupportOptionalCaseSensitiveSorting) {
+  EXPECT_FALSE(FmtStyle.SortIncludes == FormatStyle::SI_CaseSensitive);
+
+  FmtStyle.SortIncludes = FormatStyle::SI_CaseSensitive;
+
+  EXPECT_EQ("#include \"A/B.h\"\n"
+"#include \"A/b.h\"\n"
+"#include \"a/b.h\"\n"
+"#include \"B/A.h\"\n"
+"#include \"B/a.h\"\n",
+sort("#include \"B/a.h\"\n"
+ "#include \"B/A.h\"\n"
+ "#include \"A/B.h\"\n"
+ "#include \"a/b.h\"\n"
+ "#include \"A/b.h\"\n",
+ "a.h"));
+
+  Style.IncludeBlocks = clang::tooling::IncludeStyle::IBS_Regroup;
+  Style.IncludeCategories = {
+  {"^\"", 1, 0, false}, {"^<.*\\.h>$", 2, 0, false}, {"^<", 3, 0, false}};
+
+  StringRef UnsortedCode = "#include \"qt.h\"\n"
+   "#include \n"
+   "#include \n"
+   "#include \n"
+   "#include \n"
+   "#include \"vlib.h\"\n"
+   "#include \"Vlib.h\"\n"
+   "#include \"AST.h\"\n";
+
+  EXPECT_EQ("#include \"AST.h\"\n"
+"#include \"qt.h\"\n"
+"#include \"Vlib.h\"\n"
+"#include \"vlib.h\"\n"
+"\n"
+"#include \n"
+"#include \n"
+"\n"
+"#include \n"
+"#include \n",
+sort(UnsortedCode));
+}
+
 TEST_F(SortIncludesTest, SupportCaseInsensitiveMatching) {
   // Setup an regex for main includes so we can cover those as well.
   Style.IncludeIsMainRegex = "([-_](test|unittest))?$";
Index: clang/unittests/Format/SortImportsTestJava.cpp
===
--- clang/unittests/Format/SortImportsTestJava.cpp
+++ clang/unittests/Format/SortImportsTestJava.cpp
@@ -32,7 +32,7 @@
   SortImportsTestJava() {
 FmtStyle = getGoogleStyle(FormatStyle::LK_Java);
 FmtStyle.JavaImportGroups = {"com.test", "org", "com"};
-FmtStyle.SortIncludes = true;
+FmtStyle.SortIncludes = FormatStyle::SI_CaseInsensitive;
   }
 };
 
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -15463,7 +15463,6 @@
   CHECK_PARSE_BOOL(ObjCSpaceBeforeProtocolList);
   CHECK_PARSE_BOOL(Cpp11BracedListStyle);
   CHECK_PARSE_BOOL(ReflowComments);
-  CHECK_PARSE_BOOL(SortIncludes);
   CHECK_PARSE_BOOL(SortUsingDeclarations);
   CHECK_PARSE_BOOL(SpacesInParentheses);
   CHECK_PARSE_BOOL(SpacesInSquareBrackets);
@@ -15959,6 +15958,16 @@
   CHECK_PARSE("IncludeIsMainSourceRegex: 'abc$'",
   IncludeStyle.IncludeIsMainSourceRegex, "abc$");
 
+  Style.SortIncludes = FormatStyle::SI_Never;
+  CHECK_PARSE("SortIncludes: true", SortIncludes,
+  FormatStyle::SI_CaseInsensitive);
+  CHECK_PARSE("SortIncludes: false", SortIncludes, FormatStyle::SI_Never);
+  CHECK_PARSE("SortIncludes: CaseInsensitive", SortIncludes,
+  FormatStyle::SI_CaseInsensitive);
+  CHECK_PARSE("SortIncludes: CaseSensitive", SortIncludes,
+  FormatStyle::SI_CaseSensitive);
+  CHECK_PARSE("SortIncludes: Never", SortIncludes, FormatStyle::SI_Never);
+
   Style.RawStringFormats.clear();
   std::vector ExpectedRawStringFormats = {
   {
@@ -17970,7 +17979,7 @@
 "#include \"b.h\"\n")});
 
   format::FormatStyle Style = format::getLLVMStyle();
-  Style.SortIncludes = true;
+  Style.SortIncludes = FormatStyle::SI_Ca

[clang] a8105b3 - [clang-format] Add case aware include sorting.

[Marek Kurdej via cfe-commits]

Author: Kent Sommer
Date: 2021-02-02T15:12:27+01:00
New Revision: a8105b3766e4195ca2390cd0714e07406bc8a4a5

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

LOG: [clang-format] Add case aware include sorting.

Adds an option to [clang-format] which sorts headers in an alphabetical manner 
using case only for tie-breakers. The options is off by default in favor of the 
current ASCIIbetical sorting style.

Reviewed By: MyDeveloperDay, curdeius, HazardyKnusperkeks

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

Added: 


Modified: 
clang/docs/ClangFormatStyleOptions.rst
clang/docs/ReleaseNotes.rst
clang/include/clang/Format/Format.h
clang/lib/Format/Format.cpp
clang/tools/clang-format/ClangFormat.cpp
clang/unittests/Format/FormatTest.cpp
clang/unittests/Format/SortImportsTestJava.cpp
clang/unittests/Format/SortIncludesTest.cpp

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index a28efa5dad04..d55c0d59b36a 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -3004,14 +3004,43 @@ the configuration (without a prefix: ``Auto``).
  /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with 
plenty of
   * information */
 
-**SortIncludes** (``bool``)
-  If ``true``, clang-format will sort ``#includes``.
+**SortIncludes** (``SortIncludesOptions``)
+  Controls if and how clang-format will sort ``#includes``.
 
-  .. code-block:: c++
+  Possible Values:
 
- false: true:
- #include "b.h" vs. #include "a.h"
- #include "a.h" #include "b.h"
+  * ``SI_Never`` (in configuration ``Never``)
+Includes are never sorted.
+
+.. code-block:: c++
+
+  #include "B/A.h"
+  #include "A/B.h"
+  #include "a/b.h"
+  #include "A/b.h"
+  #include "B/a.h"
+
+  * ``SI_CaseInsensitive`` (in configuration ``CaseInsensitive``)
+Includes are sorted in an ASCIIbetical or case insensitive fashion.
+
+.. code-block:: c++
+
+  #include "A/B.h"
+  #include "A/b.h"
+  #include "B/A.h"
+  #include "B/a.h"
+  #include "a/b.h"
+
+  * ``SI_CaseSensitive`` (in configuration ``CaseSensitive``)
+Includes are sorted in an alphabetical or case sensitive fashion.
+
+.. code-block:: c++
+
+  #include "A/B.h"
+  #include "A/b.h"
+  #include "a/b.h"
+  #include "B/A.h"
+  #include "B/a.h"
 
 **SortJavaStaticImport** (``SortJavaStaticImportOptions``)
   When sorting Java imports, by default static imports are placed before

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 6c5c993f98b1..d1a5156f0d00 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -159,6 +159,35 @@ clang-format
 - Option ``SpacesInLineCommentPrefix`` has been added to control the
   number of spaces in a line comments prefix.
 
+- Option ``SortIncludes`` has been updated from a ``bool`` to an
+  ``enum`` with backwards compatibility. In addition to the previous
+  ``true``/``false`` states (now ``CaseInsensitive``/``Never``), a third
+  state has been added (``CaseSensitive``) which causes an alphabetical sort
+  with case used as a tie-breaker.
+
+  .. code-block:: c++
+
+// Never (previously false)
+#include "B/A.h"
+#include "A/B.h"
+#include "a/b.h"
+#include "A/b.h"
+#include "B/a.h"
+
+// CaseInsensitive (previously true)
+#include "A/B.h"
+#include "A/b.h"
+#include "B/A.h"
+#include "B/a.h"
+#include "a/b.h"
+
+// CaseSensitive
+#include "A/B.h"
+#include "A/b.h"
+#include "a/b.h"
+#include "B/A.h"
+#include "B/a.h"
+
 libclang
 
 

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 269707fedaac..7cedbfb80610 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -2613,13 +2613,44 @@ struct FormatStyle {
   bool ReflowComments;
   // clang-format on
 
-  /// If ``true``, clang-format will sort ``#includes``.
-  /// \code
-  ///false: true:
-  ///#include "b.h" vs. #include "a.h"
-  ///#include "a.h" #include "b.h"
-  /// \endcode
-  bool SortIncludes;
+  /// Include sorting options.
+  enum SortIncludesOptions : unsigned char {
+/// Includes are never sorted.
+/// \code
+///#include "B/A.h"
+///#include "A/B.h"
+///#include "a/b.h"
+///#include "A/b.h"
+///#include "B/a.h"
+/// \endcode
+SI_Never,
+/// Includes are sorted in an ASCIIbetical or case insensitive fashion

[PATCH] D95448: [flang][driver] Add support for `-J/-module-dir`

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski added a comment.

LGTM!

Thank you for addressing my comments, (`DELETEME` can be fixed when pushing 
upstream)! From what I can see you've also addressed all of Tim's comments, but 
could you wait a day or two before merging this? Just in case I missed 
something, or Tim or somebody else has further comments.




Comment at: flang/lib/Frontend/CompilerInvocation.cpp:191-192
+  
+  //for (const auto *currentArg : 
args.filtered(clang::driver::options::OPT_module_dir))  
+  //   moduleDir = currentArg->getValue();
+  auto moduleDirList = 
args.getAllArgValues(clang::driver::options::OPT_module_dir);

DELETEME



Comment at: flang/lib/Frontend/FrontendActions.cpp:81-82
   // TODO: These should be specifiable by users. For now just use the defaults.
-  common::LanguageFeatureControl features;
-  Fortran::common::IntrinsicTypeDefaultKinds defaultKinds;
+  // common::LanguageFeatureControl features;
+  // Fortran::common::IntrinsicTypeDefaultKinds defaultKinds;
 

DELETEME


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

https://reviews.llvm.org/D95448

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

[clang] 4f1320b - Revert "[InstrProfiling] Use !associated metadata for counters, data and values"

[Tom Weaver via cfe-commits]

Author: Tom Weaver
Date: 2021-02-02T14:19:31Z
New Revision: 4f1320b77d1780dd7532f8ca8b123c13ab55bf1a

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

LOG: Revert "[InstrProfiling] Use !associated metadata for counters, data and 
values"

This reverts commit df3e39f60b356ca9dbfc11e96e5fdda30afa7acb.

introduced failing test instrprof-gc-sections.c
causing build bot to fail:
http://lab.llvm.org:8011/#/builders/53/builds/1184

Added: 


Modified: 
clang/lib/CodeGen/BackendUtil.cpp
llvm/include/llvm/Transforms/Instrumentation.h
llvm/include/llvm/Transforms/Instrumentation/InstrProfiling.h
llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp
llvm/test/Instrumentation/InstrProfiling/icall.ll
llvm/test/Instrumentation/InstrProfiling/linkage.ll
llvm/test/Transforms/PGOProfile/counter_promo.ll
llvm/test/Transforms/PGOProfile/counter_promo_mexits.ll

Removed: 
compiler-rt/test/profile/instrprof-gc-sections.c
llvm/test/Transforms/PGOProfile/associated.ll



diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index f995c4702419..52bcd971dc8c 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -615,9 +615,6 @@ getInstrProfOptions(const CodeGenOptions &CodeGenOpts,
   Options.NoRedZone = CodeGenOpts.DisableRedZone;
   Options.InstrProfileOutput = CodeGenOpts.InstrProfileOutput;
   Options.Atomic = CodeGenOpts.AtomicProfileUpdate;
-  std::pair BinutilsVersion =
-  llvm::TargetMachine::parseBinutilsVersion(CodeGenOpts.BinutilsVersion);
-  Options.CounterLinkOrder = BinutilsVersion >= std::make_pair(2, 36);
   return Options;
 }
 

diff  --git a/compiler-rt/test/profile/instrprof-gc-sections.c 
b/compiler-rt/test/profile/instrprof-gc-sections.c
deleted file mode 100644
index b1f0720846af..
--- a/compiler-rt/test/profile/instrprof-gc-sections.c
+++ /dev/null
@@ -1,91 +0,0 @@
-// REQUIRES: linux, lld-available
-
-// RUN: %clang_profgen=%t.profraw -fuse-ld=lld -fcoverage-mapping -mllvm 
-counter-link-order -mllvm -enable-name-compression=false -DCODE=1 
-ffunction-sections -fdata-sections -Wl,--gc-sections -o %t %s
-// RUN: %run %t
-// RUN: llvm-profdata merge -o %t.profdata %t.profraw
-// RUN: llvm-profdata show --all-functions %t.profdata | FileCheck %s 
-check-prefix=PROF
-// RUN: llvm-cov show %t -instr-profile %t.profdata | FileCheck %s 
-check-prefix=COV
-// RUN: llvm-nm %t | FileCheck %s -check-prefix=NM
-// RUN: llvm-readelf -x __llvm_prf_names %t | FileCheck %s 
-check-prefix=PRF_NAMES
-// RUN: llvm-readelf -x __llvm_prf_cnts %t | FileCheck %s 
-check-prefix=PRF_CNTS
-
-// RUN: %clang_lto_profgen=%t.lto.profraw -fuse-ld=lld -fcoverage-mapping 
-mllvm -counter-link-order -mllvm -enable-name-compression=false -DCODE=1 
-ffunction-sections -fdata-sections -Wl,--gc-sections -flto -o %t.lto %s
-// RUN: %run %t.lto
-// RUN: llvm-profdata merge -o %t.lto.profdata %t.lto.profraw
-// RUN: llvm-profdata show --all-functions %t.lto.profdata | FileCheck %s 
-check-prefix=PROF
-// RUN: llvm-cov show %t.lto -instr-profile %t.lto.profdata | FileCheck %s 
-check-prefix=COV
-// RUN: llvm-nm %t.lto | FileCheck %s -check-prefix=NM
-// RUN: llvm-readelf -x __llvm_prf_names %t.lto | FileCheck %s 
-check-prefix=PRF_NAMES
-// RUN: llvm-readelf -x __llvm_prf_cnts %t.lto | FileCheck %s 
-check-prefix=PRF_CNTS
-
-// Note: We expect foo() and some of the profiling data associated with it to
-// be garbage collected.
-
-// Note: When there is no code in a program, we expect to see the exact same
-// set of external functions provided by the profile runtime.
-
-// RUN: %clang_profgen -fuse-ld=lld -fcoverage-mapping -mllvm 
-counter-link-order -ffunction-sections -fdata-sections -Wl,--gc-sections 
-shared -o %t.nocode.so %s
-// RUN: llvm-nm -jgU %t.nocode.so | grep -vE "__start_.*|__stop_.*" > 
%t.nocode.syms
-// RUN: llvm-nm -jgU %t | grep -vE "main|_start|_IO_stdin_used|__libc_.*" > 
%t.code.syms
-// RUN: 
diff  %t.nocode.syms %t.code.syms
-
-// Note: We also check the IR instrumentation and expect foo() to be garbage
-// collected as well.
-
-// RUN: %clang_pgogen=%t.pgo.profraw -fuse-ld=lld -mllvm -counter-link-order 
-DCODE=1 -ffunction-sections -fdata-sections -Wl,--gc-sections -o %t.pgo %s
-// RUN: %run %t.pgo
-// RUN: llvm-profdata merge -o %t.pgo.profdata %t.pgo.profraw
-// RUN: llvm-profdata show --all-functions %t.pgo.profdata | FileCheck %s 
-check-prefix=PGO
-// RUN: llvm-nm %t.pgo | FileCheck %s -check-prefix=NM
-
-#ifdef CODE
-
-// COV: [[@LINE+1]]{{ *}}|{{ *}}0|void foo()
-void foo() {}
-
-// COV: [[@LINE+1]]{{ *}}|{{ *}}1|int main
-int main() { return 0; }
-
-#endif // CODE
-
-// NM-NOT: foo
-
-// PROF: Counters:
-// PROF-NEXT:   main:
-// PROF-NEXT: Hash:
-// PROF-NEXT: Co

[clang] 9e5fc57 - [ASTMatchers] Ignore parts of BindingDecls which are not spelled in source

[Stephen Kelly via cfe-commits]

Author: Stephen Kelly
Date: 2021-02-02T14:23:13Z
New Revision: 9e5fc578f99aaa3f01374d3f09fda75fa7d0239e

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

LOG: [ASTMatchers] Ignore parts of BindingDecls which are not spelled in source

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

Added: 


Modified: 
clang/include/clang/AST/ASTNodeTraverser.h
clang/lib/ASTMatchers/ASTMatchFinder.cpp
clang/unittests/AST/ASTTraverserTest.cpp
clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTNodeTraverser.h 
b/clang/include/clang/AST/ASTNodeTraverser.h
index bb5b0c73f028..c4f0355b352e 100644
--- a/clang/include/clang/AST/ASTNodeTraverser.h
+++ b/clang/include/clang/AST/ASTNodeTraverser.h
@@ -438,6 +438,8 @@ class ASTNodeTraverser
   }
 
   void VisitBindingDecl(const BindingDecl *D) {
+if (Traversal == TK_IgnoreUnlessSpelledInSource)
+  return;
 if (const auto *E = D->getBinding())
   Visit(E);
   }

diff  --git a/clang/lib/ASTMatchers/ASTMatchFinder.cpp 
b/clang/lib/ASTMatchers/ASTMatchFinder.cpp
index 69957a952d17..58e69bb29df6 100644
--- a/clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ b/clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -1216,6 +1216,8 @@ bool MatchASTVisitor::TraverseDecl(Decl *DeclNode) {
   ScopedChildren = true;
 if (FD->isTemplateInstantiation())
   ScopedTraversal = true;
+  } else if (isa(DeclNode)) {
+ScopedChildren = true;
   }
 
   ASTNodeNotSpelledInSourceScope RAII1(this, ScopedTraversal);

diff  --git a/clang/unittests/AST/ASTTraverserTest.cpp 
b/clang/unittests/AST/ASTTraverserTest.cpp
index 94b9572ad50d..d633f90b57d2 100644
--- a/clang/unittests/AST/ASTTraverserTest.cpp
+++ b/clang/unittests/AST/ASTTraverserTest.cpp
@@ -1148,6 +1148,15 @@ void callDefaultArg()
 {
   hasDefaultArg(42);
 }
+
+void decomposition()
+{
+int arr[3];
+auto &[f, s, t] = arr;
+
+f = 42;
+}
+
 )cpp",
{"-std=c++20"});
 
@@ -1443,6 +1452,46 @@ CallExpr
 CallExpr
 |-DeclRefExpr 'hasDefaultArg'
 `-IntegerLiteral
+)cpp");
+  }
+
+  {
+auto FN = ast_matchers::match(
+functionDecl(hasName("decomposition"),
+ hasDescendant(decompositionDecl().bind("decomp"))),
+AST2->getASTContext());
+EXPECT_EQ(FN.size(), 1u);
+
+EXPECT_EQ(
+dumpASTString(TK_AsIs, FN[0].getNodeAs("decomp")),
+R"cpp(
+DecompositionDecl ''
+|-DeclRefExpr 'arr'
+|-BindingDecl 'f'
+| `-ArraySubscriptExpr
+|   |-ImplicitCastExpr
+|   | `-DeclRefExpr ''
+|   `-IntegerLiteral
+|-BindingDecl 's'
+| `-ArraySubscriptExpr
+|   |-ImplicitCastExpr
+|   | `-DeclRefExpr ''
+|   `-IntegerLiteral
+`-BindingDecl 't'
+  `-ArraySubscriptExpr
+|-ImplicitCastExpr
+| `-DeclRefExpr ''
+`-IntegerLiteral
+)cpp");
+
+EXPECT_EQ(dumpASTString(TK_IgnoreUnlessSpelledInSource,
+FN[0].getNodeAs("decomp")),
+  R"cpp(
+DecompositionDecl ''
+|-DeclRefExpr 'arr'
+|-BindingDecl 'f'
+|-BindingDecl 's'
+`-BindingDecl 't'
 )cpp");
   }
 }

diff  --git a/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp 
b/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
index 06c2bbc29e5c..b756cf815aaf 100644
--- a/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ b/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2591,6 +2591,48 @@ B func1() { return 42; }
 Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
 std::make_unique>("allExprs", 1)));
   }
+
+  Code = R"cpp(
+void foo()
+{
+int arr[3];
+auto &[f, s, t] = arr;
+
+f = 42;
+}
+  )cpp";
+  {
+auto M = bindingDecl(hasName("f"));
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_AsIs, M), true, 
{"-std=c++17"}));
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+ true, {"-std=c++17"}));
+  }
+  {
+auto M = bindingDecl(hasName("f"), has(expr()));
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_AsIs, M), true, 
{"-std=c++17"}));
+EXPECT_FALSE(
+matchesConditionally(Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+ true, {"-std=c++17"}));
+  }
+  {
+auto M = integerLiteral(hasAncestor(bindingDecl(hasName("f";
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_AsIs, M), true, 
{"-std=c++17"}));
+EXPECT_FALSE(
+matchesConditionally(Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+ true, {"-std=c++17"}));
+  }
+  {
+auto M = declRefExpr(hasAncestor(bindingDecl(hasName("f";
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_AsIs, M), true, 
{"-std=c++1

[PATCH] D95740: [ASTMatchers] Ignore parts of BindingDecls which are not spelled in source

[Stephen Kelly 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 rG9e5fc578f99a: [ASTMatchers] Ignore parts of BindingDecls 
which are not spelled in source (authored by stephenkelly).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95740

Files:
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/lib/ASTMatchers/ASTMatchFinder.cpp
  clang/unittests/AST/ASTTraverserTest.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2591,6 +2591,48 @@
 Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
 std::make_unique>("allExprs", 1)));
   }
+
+  Code = R"cpp(
+void foo()
+{
+int arr[3];
+auto &[f, s, t] = arr;
+
+f = 42;
+}
+  )cpp";
+  {
+auto M = bindingDecl(hasName("f"));
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_AsIs, M), true, {"-std=c++17"}));
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+ true, {"-std=c++17"}));
+  }
+  {
+auto M = bindingDecl(hasName("f"), has(expr()));
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_AsIs, M), true, {"-std=c++17"}));
+EXPECT_FALSE(
+matchesConditionally(Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+ true, {"-std=c++17"}));
+  }
+  {
+auto M = integerLiteral(hasAncestor(bindingDecl(hasName("f";
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_AsIs, M), true, {"-std=c++17"}));
+EXPECT_FALSE(
+matchesConditionally(Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+ true, {"-std=c++17"}));
+  }
+  {
+auto M = declRefExpr(hasAncestor(bindingDecl(hasName("f";
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_AsIs, M), true, {"-std=c++17"}));
+EXPECT_FALSE(
+matchesConditionally(Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+ true, {"-std=c++17"}));
+  }
 }
 
 TEST(Traversal, traverseNoImplicit) {
Index: clang/unittests/AST/ASTTraverserTest.cpp
===
--- clang/unittests/AST/ASTTraverserTest.cpp
+++ clang/unittests/AST/ASTTraverserTest.cpp
@@ -1148,6 +1148,15 @@
 {
   hasDefaultArg(42);
 }
+
+void decomposition()
+{
+int arr[3];
+auto &[f, s, t] = arr;
+
+f = 42;
+}
+
 )cpp",
{"-std=c++20"});
 
@@ -1443,6 +1452,46 @@
 CallExpr
 |-DeclRefExpr 'hasDefaultArg'
 `-IntegerLiteral
+)cpp");
+  }
+
+  {
+auto FN = ast_matchers::match(
+functionDecl(hasName("decomposition"),
+ hasDescendant(decompositionDecl().bind("decomp"))),
+AST2->getASTContext());
+EXPECT_EQ(FN.size(), 1u);
+
+EXPECT_EQ(
+dumpASTString(TK_AsIs, FN[0].getNodeAs("decomp")),
+R"cpp(
+DecompositionDecl ''
+|-DeclRefExpr 'arr'
+|-BindingDecl 'f'
+| `-ArraySubscriptExpr
+|   |-ImplicitCastExpr
+|   | `-DeclRefExpr ''
+|   `-IntegerLiteral
+|-BindingDecl 's'
+| `-ArraySubscriptExpr
+|   |-ImplicitCastExpr
+|   | `-DeclRefExpr ''
+|   `-IntegerLiteral
+`-BindingDecl 't'
+  `-ArraySubscriptExpr
+|-ImplicitCastExpr
+| `-DeclRefExpr ''
+`-IntegerLiteral
+)cpp");
+
+EXPECT_EQ(dumpASTString(TK_IgnoreUnlessSpelledInSource,
+FN[0].getNodeAs("decomp")),
+  R"cpp(
+DecompositionDecl ''
+|-DeclRefExpr 'arr'
+|-BindingDecl 'f'
+|-BindingDecl 's'
+`-BindingDecl 't'
 )cpp");
   }
 }
Index: clang/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -1216,6 +1216,8 @@
   ScopedChildren = true;
 if (FD->isTemplateInstantiation())
   ScopedTraversal = true;
+  } else if (isa(DeclNode)) {
+ScopedChildren = true;
   }
 
   ASTNodeNotSpelledInSourceScope RAII1(this, ScopedTraversal);
Index: clang/include/clang/AST/ASTNodeTraverser.h
===
--- clang/include/clang/AST/ASTNodeTraverser.h
+++ clang/include/clang/AST/ASTNodeTraverser.h
@@ -438,6 +438,8 @@
   }
 
   void VisitBindingDecl(const BindingDecl *D) {
+if (Traversal == TK_IgnoreUnlessSpelledInSource)
+  return;
 if (const auto *E = D->getBinding())
   Visit(E);
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] 6ac3fd9 - [clangd] Fix race in Global CDB shutdown

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2021-02-02T15:24:14+01:00
New Revision: 6ac3fd9706047304c52a678884122a3a6bc55432

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

LOG: [clangd] Fix race in Global CDB shutdown

I believe the atomic write can be reordered after the notify, and that
seems to be happening on mac m1: http://45.33.8.238/macm1/2654/step_8.txt
In practice maybe seq_cst is enough? But no reason not to lock here.

https://bugs.llvm.org/show_bug.cgi?id=48998

Added: 


Modified: 
clang-tools-extra/clangd/GlobalCompilationDatabase.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp 
b/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
index afe38993ef28..a38c8a57d161 100644
--- a/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
+++ b/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -553,7 +554,10 @@ class 
DirectoryBasedGlobalCompilationDatabase::BroadcastThread {
   }
 
   ~BroadcastThread() {
-ShouldStop.store(true, std::memory_order_release);
+{
+  std::lock_guard Lock(Mu);
+  ShouldStop.store(true, std::memory_order_release);
+}
 CV.notify_all();
 Thread.join();
   }



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

[PATCH] D92808: [ObjC][ARC] Use operand bundle 'clang.arc.rv' instead of explicitly emitting retainRV or claimRV calls in the IR

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

Thanks for the updates! The LLVM side of things now looks good to me. Could you 
also add a description of the new bundle to LangRef 
https://llvm.org/docs/LangRef.html#operand-bundles?

In D92808#2535593 , @ahatanak wrote:

> We could run another pass to clean up the IR after inlining, but I think it's 
> better to do the cleanup right after the callee function is cloned in the 
> caller function.

Thanks for elaborating. Given that it is isolated to a single place and the 
inliner already has logic to deal with a few different intrinsics/bundle types, 
I think that should be fine.




Comment at: llvm/include/llvm/IR/Intrinsics.td:449
 [llvm_vararg_ty]>;
+def int_objc_clang_arc_noop_use : Intrinsic<[],
+[llvm_vararg_ty],

ahatanak wrote:
> fhahn wrote:
> > Can this be a `DefaultAttrIntrinsics` (which adds ` nofree nosync nounwind 
> > willreturn`)?
> > 
> > Same probably for all/most objc_* intrinsics.
> I'll change the other intrinsics in a separate patch.
SGTM. thanks!



Comment at: llvm/lib/Transforms/Utils/InlineFunction.cpp:1655
+///
+/// 1. If there is a call to autoreleasaeRV that takes a pointer to the 
returned
+///object in the callee return block, the autoreleaseRV call and the

nit: typo `autoreleasaeRV`



Comment at: llvm/lib/Transforms/Utils/InlineFunction.cpp:1669
+   const SmallVectorImpl &Returns) {
+  Module *Mod = CB.getParent()->getParent()->getParent();
+  bool IsRetainRV = objcarc::hasRVOpBundle(&CB, true), IsClaimRV = !IsRetainRV;

nit: Can you just use `CB.getModule()`?



Comment at: llvm/lib/Transforms/Utils/InlineFunction.cpp:1673
+  for (auto *RI : Returns) {
+Value *RetOpnd = llvm::objcarc::GetRCIdentityRoot(RI->getOperand(0));
+BasicBlock::reverse_iterator I = ++(RI->getIterator().getReverse());

we are in the `llvm::` namespace here I think, so this should not be needed ? 
above you use the `objcarc` namespace without `llvm::` prefix as well. Same in 
other places in the function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92808

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

[PATCH] D94880: Add clang-query support for mapAnyOf

[Stephen Kelly via Phabricator via cfe-commits]

steveire updated this revision to Diff 320774.
steveire added a comment.

Update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94880

Files:
  clang/include/clang/ASTMatchers/Dynamic/Diagnostics.h
  clang/include/clang/ASTMatchers/Dynamic/Parser.h
  clang/include/clang/ASTMatchers/Dynamic/Registry.h
  clang/include/clang/ASTMatchers/Dynamic/VariantValue.h
  clang/lib/ASTMatchers/Dynamic/Diagnostics.cpp
  clang/lib/ASTMatchers/Dynamic/Marshallers.h
  clang/lib/ASTMatchers/Dynamic/Parser.cpp
  clang/lib/ASTMatchers/Dynamic/Registry.cpp
  clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
  clang/unittests/ASTMatchers/Dynamic/ParserTest.cpp

Index: clang/unittests/ASTMatchers/Dynamic/ParserTest.cpp
===
--- clang/unittests/ASTMatchers/Dynamic/ParserTest.cpp
+++ clang/unittests/ASTMatchers/Dynamic/ParserTest.cpp
@@ -32,6 +32,17 @@
 return M.getID().second;
   }
 
+  bool isBuilderMatcher(MatcherCtor) const override { return false; }
+
+  ASTNodeKind nodeMatcherType(MatcherCtor) const override { return {}; }
+
+  internal::MatcherDescriptorPtr
+  buildMatcherCtor(MatcherCtor, SourceRange NameRange,
+   ArrayRef Args,
+   Diagnostics *Error) const override {
+return internal::MatcherDescriptorPtr{nullptr};
+  }
+
   void parse(StringRef Code) {
 Diagnostics Error;
 VariantValue Value;
@@ -329,7 +340,7 @@
 "1:5: Invalid token <(> found when looking for a value.",
 ParseWithError("Foo(("));
   EXPECT_EQ("1:7: Expected end of code.", ParseWithError("expr()a"));
-  EXPECT_EQ("1:11: Malformed bind() expression.",
+  EXPECT_EQ("1:11: Period not followed by valid chained call.",
 ParseWithError("isArrow().biind"));
   EXPECT_EQ("1:15: Malformed bind() expression.",
 ParseWithError("isArrow().bind"));
@@ -340,6 +351,20 @@
   EXPECT_EQ("1:1: Error building matcher isArrow.\n"
 "1:1: Matcher does not support binding.",
 ParseWithError("isArrow().bind(\"foo\")"));
+  EXPECT_EQ("1:1: Error building matcher isArrow.\n"
+"1:11: Matcher does not support with call.",
+ParseWithError("isArrow().with"));
+  EXPECT_EQ(
+  "1:22: Error parsing matcher. Found token  while looking for '('.",
+  ParseWithError("mapAnyOf(ifStmt).with"));
+  EXPECT_EQ(
+  "1:22: Error parsing matcher. Found end-of-code while looking for ')'.",
+  ParseWithError("mapAnyOf(ifStmt).with("));
+  EXPECT_EQ("1:1: Failed to build matcher: mapAnyOf.",
+ParseWithError("mapAnyOf()"));
+  EXPECT_EQ("1:1: Error parsing argument 1 for matcher mapAnyOf.\n1:1: Failed "
+"to build matcher: mapAnyOf.",
+ParseWithError("mapAnyOf(\"foo\")"));
   EXPECT_EQ("Input value has unresolved overloaded type: "
 "Matcher",
 ParseMatcherWithError("hasBody(stmt())"));
@@ -470,7 +495,8 @@
 )matcher";
 M = Parser::parseMatcherExpression(Code, nullptr, &NamedValues, &Error);
 EXPECT_FALSE(M.hasValue());
-EXPECT_EQ("1:11: Malformed bind() expression.", Error.toStringFull());
+EXPECT_EQ("1:11: Period not followed by valid chained call.",
+  Error.toStringFull());
   }
 
   {
@@ -515,6 +541,29 @@
   ASSERT_EQ(1u, Comps.size());
   EXPECT_EQ("bind(\"", Comps[0].TypedText);
   EXPECT_EQ("bind", Comps[0].MatcherDecl);
+
+  Code = "mapAny";
+  Comps = Parser::completeExpression(Code, 6);
+  ASSERT_EQ(1u, Comps.size());
+  EXPECT_EQ("Of(", Comps[0].TypedText);
+  EXPECT_EQ("Matcher "
+"mapAnyOf(NestedNameSpecifierLoc|QualType|TypeLoc|"
+"NestedNameSpecifier|Decl|Stmt|Type...)",
+Comps[0].MatcherDecl);
+
+  Code = "mapAnyOf(ifStmt).";
+  Comps = Parser::completeExpression(Code, 17);
+  ASSERT_EQ(2u, Comps.size());
+  EXPECT_EQ("bind(\"", Comps[0].TypedText);
+  EXPECT_EQ("bind", Comps[0].MatcherDecl);
+  EXPECT_EQ("with(\"", Comps[1].TypedText);
+  EXPECT_EQ("with", Comps[1].MatcherDecl);
+
+  Code = "mapAnyOf(ifS";
+  Comps = Parser::completeExpression(Code, 12);
+  ASSERT_EQ(1u, Comps.size());
+  EXPECT_EQ("tmt", Comps[0].TypedText);
+  EXPECT_EQ("ifStmt", Comps[0].MatcherDecl);
 }
 
 TEST(ParserTest, CompletionNamedValues) {
Index: clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
===
--- clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
+++ clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
@@ -22,9 +22,11 @@
 std::string ArgKind::asString() const {
   switch (getArgKind()) {
   case AK_Matcher:
-return (Twine("Matcher<") + MatcherKind.asStringRef() + ">").str();
+return (Twine("Matcher<") + NodeKind.asStringRef() + ">").str();
   case AK_Boolean:
 return "boolean";
+  case AK_Node:
+return NodeKind.asStringRef().str();
   case AK_Double:
 return "double";
   case AK_Unsigned:
@@ -38,13 +40,13 @@

[PATCH] D94880: Add clang-query support for mapAnyOf

[Stephen Kelly via Phabricator via cfe-commits]

steveire added a comment.

In D94880#2536399 , @aaron.ballman 
wrote:

> I think there should be some documentation change for the new `with` 
> functionality.

It's already documented in 
https://clang.llvm.org/docs/LibASTMatchersReference.html , just like all the 
other functionality.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94880

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

[PATCH] D95852: [clangd] Report xref for base methods.

[Utkarsh Saxena via Phabricator via cfe-commits]

usaxena95 added inline comments.



Comment at: clang-tools-extra/clangd/unittests/XRefsTests.cpp:1902
+void test(BaseBase* BB, Base* B, Derived* D) {
+  BB->func();  // refs to base's base method are not reported.
+  B->[[func]]();  // References to the base method.

hokein wrote:
> ah, this is a good case!  I think we should include the base's base method as 
> part of the refs -- because BB->func() can actually call D::func if BB points 
> to a `Derived` object.
> 
> the fix is to add ids from `overridden_methods` recursively.
> 
Yeah we can do that. Although I had intentionally left those out considering 
the number of references would increase significantly if we do it for the 
complete type hierarchy. Also since LSP doesn't provide a way to annotate these 
kind of references, it would be hard for users to find exact refs (to 
Derived::foo()).
WDYT ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95852

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

[PATCH] D69560: [clang-tidy] Add 'bugprone-easily-swappable-parameters' check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:58
+
+namespace {
+

whisperity wrote:
> aaron.ballman wrote:
> > Is there a need for the anonymous namespace? (We typically only use them 
> > when defining a class and try to make them as narrow in scope as possible, 
> > and use `static` for function declarations instead.)
> There will be two major parts, the modelling (and which is extended down the 
> line with new models like implicit conversions) and the filtering (which 
> throws away or breaks up results). Should I cut out the anonymous namespace? 
> How about the inner namespaces, may they stay?
The inner namespaces are totally fine. As for the anon namespace, I personally 
don't have a strong opinion against it, I brought it up mostly as a coding 
style guide nit, but I think removing it is helpful so that it's more obvious 
when a function has internal vs external linkage from its signature.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:67
+/// The language features involved in allowing the mix between two parameters.
+enum MixFlags : unsigned char {
+  MIX_Invalid = 0, //< Sentinel bit pattern. DO NOT USE!

whisperity wrote:
> aaron.ballman wrote:
> > Does using the fixed underlying type buy us something? As best I can tell, 
> > this will introduce a fair amount of implicit promotions to `int` anyway.
> Will it? I thought if I use the proper LLVM bitmask/flag enum thing it will 
> work properly. For now, it is good for the bit flag debug print, because it 
> only prints 8 numbers, not 32.
Ah, perhaps that's the case -- I'm not super familiar with the LLVM 
bitmask/flag macros. That said, if you think there's good utility for it, I'm 
happy to leave it as-is.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:90-91
+
+  void sanitise() {
+assert(Flags != MIX_Invalid && "sanitise() called on invalid bitvec");
+// TODO: There will be statements here in further extensions of the check.

whisperity wrote:
> aaron.ballman wrote:
> > Heh, I don't know if we have any guidance on US English vs British English 
> > spellings. ;-)
> Reflexes, my bad. (Similarly how I put the pointer `*` to the left side, 
> where Stroustrup intended. At least my local pre-commit hooks take care of 
> that.) Will try to remember this.
Heh, no worries, I'm betting if we did some code searches, we'd find plenty of 
British English spellings as well. :-D



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:255
+  std::string NodeTypeName =
+  Node->getType().getAsString(Node->getASTContext().getPrintingPolicy());
+  StringRef CaptureName{NodeTypeName};

whisperity wrote:
> aaron.ballman wrote:
> > Hmm, one downside to using the printing policy to get the node name is that 
> > there can be alternative spellings for the same type that the user might 
> > reasonably expect to be applied. e.g., if the user expects to ignore `bool` 
> > datatypes and the printing policy wants to spell the type as `_Bool`, this 
> > won't behave as expected.
> But then the diagnostic is inconsistent with what the compiler is configured 
> to output as diagnostics, isn't it? Can I stringify through Clang with some 
> "default" printing policy?
The situation I'm worried about is something like this in C code:
```
#include 

void func(bool b, bool c) {}
```
because the `bool` in the function signature will expand to `_Bool` after the 
preprocessor gets to it (because of the contents of ``). If the user 
writes `bool` in their configuration file because that's what they've written 
in their function signatures, will this fail because the printing policy says 
it should be `_Bool`?

Along similar lines, I wonder about things like `struct S` vs `S` (in C), 
`signed char` vs `char`, types within anonymous namespaces (where we print 
``), etc. Basically, any time when the printing policy may 
differ from what the user lexically writes in code.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:302
+ "FowardIt", "bidirit", "BidirIt", "constiterator",
+ "const_iterator", "Const_Iterator", "Constiterator",
+ "ConstIterator"});

whisperity wrote:
> aaron.ballman wrote:
> > `reverse_iterator` and `reverse_const_iterator` too?
> > 
> > How about ranges?
> > How about ranges?
> 
> I would like to say that having an `f(RangeTy, RangeTy)` is //exactly// as 
> problematic (especially if both are non-const) as having `f(int, int)` or 
> `f(void*, void*)`, and should be taken care of the same way (relatedness 
> heuristic, name heuristic).
> The idea behind ignoring iterator-ly named things was that 

[clang] 9b0b435 - [AVR][clang] Fix a bug in AVR toolchain search paths

[Ben Shi via cfe-commits]

Author: Ben Shi
Date: 2021-02-02T22:45:52+08:00
New Revision: 9b0b435d7931bdb1fb128861cc9063a365a9e648

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

LOG: [AVR][clang] Fix a bug in AVR toolchain search paths

Reviewed By: dylanmckay, MaskRay

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

Added: 
clang/test/Driver/Inputs/basic_avr_tree/usr/bin/avr-ld
clang/test/Driver/Inputs/basic_avr_tree/usr/lib/avr/lib/libavr.a
clang/test/Driver/Inputs/basic_avr_tree/usr/lib/gcc/avr/5.4.0/libgcc.a
clang/test/Driver/avr-ld.c

Modified: 
clang/lib/Driver/ToolChains/AVR.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/AVR.cpp 
b/clang/lib/Driver/ToolChains/AVR.cpp
index ae56b7b5249e..ebbc6f2d5c79 100644
--- a/clang/lib/Driver/ToolChains/AVR.cpp
+++ b/clang/lib/Driver/ToolChains/AVR.cpp
@@ -334,10 +334,12 @@ AVRToolChain::AVRToolChain(const Driver &D, const 
llvm::Triple &Triple,
 // No avr-libc found and so no runtime linked.
 D.Diag(diag::warn_drv_avr_libc_not_found);
   } else { // We have enough information to link stdlibs
-std::string GCCRoot = std::string(GCCInstallation.getInstallPath());
+std::string GCCRoot(GCCInstallation.getInstallPath());
+std::string GCCParentPath(GCCInstallation.getParentLibPath());
 std::string LibcRoot = AVRLibcRoot.getValue();
 std::string SubPath = GetMCUSubPath(CPU);
 
+getProgramPaths().push_back(GCCParentPath + "/../bin");
 getFilePaths().push_back(LibcRoot + std::string("/lib/") + SubPath);
 getFilePaths().push_back(GCCRoot + std::string("/") + SubPath);
 
@@ -419,9 +421,10 @@ void AVR::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 
 llvm::Optional AVRToolChain::findAVRLibcInstallation() const {
   for (StringRef PossiblePath : PossibleAVRLibcLocations) {
+std::string Path = getDriver().SysRoot + PossiblePath.str();
 // Return the first avr-libc installation that exists.
-if (llvm::sys::fs::is_directory(PossiblePath))
-  return Optional(std::string(PossiblePath));
+if (llvm::sys::fs::is_directory(Path))
+  return Optional(Path);
   }
 
   return llvm::None;

diff  --git a/clang/test/Driver/Inputs/basic_avr_tree/usr/bin/avr-ld 
b/clang/test/Driver/Inputs/basic_avr_tree/usr/bin/avr-ld
new file mode 100755
index ..e69de29bb2d1

diff  --git a/clang/test/Driver/Inputs/basic_avr_tree/usr/lib/avr/lib/libavr.a 
b/clang/test/Driver/Inputs/basic_avr_tree/usr/lib/avr/lib/libavr.a
new file mode 100644
index ..e69de29bb2d1

diff  --git 
a/clang/test/Driver/Inputs/basic_avr_tree/usr/lib/gcc/avr/5.4.0/libgcc.a 
b/clang/test/Driver/Inputs/basic_avr_tree/usr/lib/gcc/avr/5.4.0/libgcc.a
new file mode 100644
index ..e69de29bb2d1

diff  --git a/clang/test/Driver/avr-ld.c b/clang/test/Driver/avr-ld.c
new file mode 100644
index ..5a37f5a93eb2
--- /dev/null
+++ b/clang/test/Driver/avr-ld.c
@@ -0,0 +1,2 @@
+// RUN: %clang -### --target=avr -mmcu=atmega328 --sysroot 
%S/Inputs/basic_avr_tree %s 2>&1 | FileCheck -check-prefix LINK %s
+// LINK: {{".*ld.*"}} {{.*}} {{"-L.*avr5"}} {{.*}} "-Tdata=0x800100" {{.*}} 
"-latmega328" "-mavr5"



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

[PATCH] D95529: [AVR][clang] Fix a bug in AVR toolchain search paths

[Ben Shi via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG9b0b435d7931: [AVR][clang] Fix a bug in AVR toolchain search 
paths (authored by benshi001).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95529

Files:
  clang/lib/Driver/ToolChains/AVR.cpp
  clang/test/Driver/Inputs/basic_avr_tree/usr/bin/avr-ld
  clang/test/Driver/Inputs/basic_avr_tree/usr/lib/avr/lib/libavr.a
  clang/test/Driver/Inputs/basic_avr_tree/usr/lib/gcc/avr/5.4.0/libgcc.a
  clang/test/Driver/avr-ld.c


Index: clang/test/Driver/avr-ld.c
===
--- /dev/null
+++ clang/test/Driver/avr-ld.c
@@ -0,0 +1,2 @@
+// RUN: %clang -### --target=avr -mmcu=atmega328 --sysroot 
%S/Inputs/basic_avr_tree %s 2>&1 | FileCheck -check-prefix LINK %s
+// LINK: {{".*ld.*"}} {{.*}} {{"-L.*avr5"}} {{.*}} "-Tdata=0x800100" {{.*}} 
"-latmega328" "-mavr5"
Index: clang/lib/Driver/ToolChains/AVR.cpp
===
--- clang/lib/Driver/ToolChains/AVR.cpp
+++ clang/lib/Driver/ToolChains/AVR.cpp
@@ -334,10 +334,12 @@
 // No avr-libc found and so no runtime linked.
 D.Diag(diag::warn_drv_avr_libc_not_found);
   } else { // We have enough information to link stdlibs
-std::string GCCRoot = std::string(GCCInstallation.getInstallPath());
+std::string GCCRoot(GCCInstallation.getInstallPath());
+std::string GCCParentPath(GCCInstallation.getParentLibPath());
 std::string LibcRoot = AVRLibcRoot.getValue();
 std::string SubPath = GetMCUSubPath(CPU);
 
+getProgramPaths().push_back(GCCParentPath + "/../bin");
 getFilePaths().push_back(LibcRoot + std::string("/lib/") + SubPath);
 getFilePaths().push_back(GCCRoot + std::string("/") + SubPath);
 
@@ -419,9 +421,10 @@
 
 llvm::Optional AVRToolChain::findAVRLibcInstallation() const {
   for (StringRef PossiblePath : PossibleAVRLibcLocations) {
+std::string Path = getDriver().SysRoot + PossiblePath.str();
 // Return the first avr-libc installation that exists.
-if (llvm::sys::fs::is_directory(PossiblePath))
-  return Optional(std::string(PossiblePath));
+if (llvm::sys::fs::is_directory(Path))
+  return Optional(Path);
   }
 
   return llvm::None;


Index: clang/test/Driver/avr-ld.c
===
--- /dev/null
+++ clang/test/Driver/avr-ld.c
@@ -0,0 +1,2 @@
+// RUN: %clang -### --target=avr -mmcu=atmega328 --sysroot %S/Inputs/basic_avr_tree %s 2>&1 | FileCheck -check-prefix LINK %s
+// LINK: {{".*ld.*"}} {{.*}} {{"-L.*avr5"}} {{.*}} "-Tdata=0x800100" {{.*}} "-latmega328" "-mavr5"
Index: clang/lib/Driver/ToolChains/AVR.cpp
===
--- clang/lib/Driver/ToolChains/AVR.cpp
+++ clang/lib/Driver/ToolChains/AVR.cpp
@@ -334,10 +334,12 @@
 // No avr-libc found and so no runtime linked.
 D.Diag(diag::warn_drv_avr_libc_not_found);
   } else { // We have enough information to link stdlibs
-std::string GCCRoot = std::string(GCCInstallation.getInstallPath());
+std::string GCCRoot(GCCInstallation.getInstallPath());
+std::string GCCParentPath(GCCInstallation.getParentLibPath());
 std::string LibcRoot = AVRLibcRoot.getValue();
 std::string SubPath = GetMCUSubPath(CPU);
 
+getProgramPaths().push_back(GCCParentPath + "/../bin");
 getFilePaths().push_back(LibcRoot + std::string("/lib/") + SubPath);
 getFilePaths().push_back(GCCRoot + std::string("/") + SubPath);
 
@@ -419,9 +421,10 @@
 
 llvm::Optional AVRToolChain::findAVRLibcInstallation() const {
   for (StringRef PossiblePath : PossibleAVRLibcLocations) {
+std::string Path = getDriver().SysRoot + PossiblePath.str();
 // Return the first avr-libc installation that exists.
-if (llvm::sys::fs::is_directory(PossiblePath))
-  return Optional(std::string(PossiblePath));
+if (llvm::sys::fs::is_directory(Path))
+  return Optional(Path);
   }
 
   return llvm::None;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D95739: [ASTMatchers] Add matchers for decomposition decls

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Looks like this doesn't link on windows: http://45.33.8.238/win/32481/step_4.txt


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95739

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

[PATCH] D69560: [clang-tidy] Add 'bugprone-easily-swappable-parameters' check

[Whisperity via Phabricator via cfe-commits]

whisperity marked 6 inline comments as done.
whisperity added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:255
+  std::string NodeTypeName =
+  Node->getType().getAsString(Node->getASTContext().getPrintingPolicy());
+  StringRef CaptureName{NodeTypeName};

aaron.ballman wrote:
> whisperity wrote:
> > aaron.ballman wrote:
> > > Hmm, one downside to using the printing policy to get the node name is 
> > > that there can be alternative spellings for the same type that the user 
> > > might reasonably expect to be applied. e.g., if the user expects to 
> > > ignore `bool` datatypes and the printing policy wants to spell the type 
> > > as `_Bool`, this won't behave as expected.
> > But then the diagnostic is inconsistent with what the compiler is 
> > configured to output as diagnostics, isn't it? Can I stringify through 
> > Clang with some "default" printing policy?
> The situation I'm worried about is something like this in C code:
> ```
> #include 
> 
> void func(bool b, bool c) {}
> ```
> because the `bool` in the function signature will expand to `_Bool` after the 
> preprocessor gets to it (because of the contents of ``). If the 
> user writes `bool` in their configuration file because that's what they've 
> written in their function signatures, will this fail because the printing 
> policy says it should be `_Bool`?
> 
> Along similar lines, I wonder about things like `struct S` vs `S` (in C), 
> `signed char` vs `char`, types within anonymous namespaces (where we print 
> ``), etc. Basically, any time when the printing policy 
> may differ from what the user lexically writes in code.
Meanwhile, I realised we are talking of two entirely distinct things. I will 
look into how this `PrintingPolicy` stuff works... I agree that the ignore 
rules (where the comment was originally posted) should respect the text written 
into the code as-is. The diagnostics printing type names could continue using 
the proper printing policy (to be in line with how Sema diagnoses, AFAIK).



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:402-403
+
+// Unfortunately, undersquiggly highlights are for some reason chewed up
+// and not respected by diagnostics from Clang-Tidy. :(
+diag(First->getLocation(), "the first parameter in the range is '%0'",

aaron.ballman wrote:
> whisperity wrote:
> > aaron.ballman wrote:
> > > Can you post a screenshot of what you mean?
> > Given
> > 
> > ```
> > Diag << SourceRange{First->getSourceRange().getBegin(), 
> > Last->getSourceRange().getEnd()};
> > ```
> > 
> > The diagnostic is still produced with only a `^` at the original 
> > `diag(Location)`, ignoring the fed `SourceRange`:
> > 
> > ```
> > /home/whisperity/LLVM/Build/../llvm-project/clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:21:18:
> >  warning: 3 adjacent parameters of 'redeclChain' of similar type ('int') 
> > are easily swapped by mistake [bugprone-easily-swappable-parameters]
> > void redeclChain(int I, int J, int K) {}
> >  ^
> > ```
> > 
> > Instead of putting all the squigglies in as the range-location highlight, 
> > like how `Sema` can diagnose:
> > 
> > ```
> > /home/whisperity/LLVM/Build/../llvm-project/clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:21:18:
> >  warning: 3 adjacent parameters of 'redeclChain' of similar type ('int') 
> > are easily swapped by mistake [bugprone-easily-swappable-parameters]
> > void redeclChain(int I, int J, int K) {}
> >  ^~~
> > ```
> > 
> > I would not want to put additional note tags in an otherwise already 
> > verbose output.
> > 
> > Back in 2019 I was investigating this issue specifically for another 
> > checker I was working on, but hit the wall... Somewhere deep inside where 
> > Tidy diagnostic stuff is translated and consumed to Clang stuff, it goes 
> > away. It shouldn't, because there are statements that seemingly copy the 
> > `Diag.Ranges` array over, but it still does not come out.
> > 
> > ... EDIT: I found [[ 
> > http://lists.llvm.org/pipermail/cfe-dev/2019-October/063676.html | the 
> > relevant mailing list post ]].
> > ... EDIT: I found the relevant mailing list post.
> 
> Oh wow, I had no idea! That's a rather unfortunate bug. :-(
Speaking of bugs, shall I put it up on Bugzilla, or see if anyone reported 
already? Would require me digging into that "where are the data structures 
copied" kind of thing to figure it out again.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.h:30
+  void storeOptions(ClangTidyOptions::OptionMap &Opts) override;
+
+  /// The minimum length of an adjacent swappable parameter range required for

aaron.ballman wrote:
> whisperity wrote:
> > aaron.ballman wrote:

[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D89909#2536331 , @bader wrote:

> In D89909#2536157 , @Anastasia wrote:
>
>> In D89909#2534790 , @bader wrote:
>>
 Regarding SYCLDevice and SYCLAddrSpaceMap I am still not very convinced 
 about the flow. Have you had any design discussion regarding this already 
 that you could point to?
>>>
>>> We discussed this with you in https://github.com/intel/llvm/pull/1039/.
>>
>> I can't see.
>
> The mapping has been discussed in this comment: 
> https://github.com/intel/llvm/pull/1039/#discussion_r369667791.

The discussion you cite is in the separate Github project, but you should have 
a discussion using LLVM channels about the design you propose for llvm-project 
repo. Also I don't think citing resources with many comments and no conclusions 
is making the review process very productive.

 My main concern is that I am not sure it fits with the main design of 
 Clang - producing IR that is to be consumed by multiple targets rather 
 than only one specific target or even an external tool. Why do you add a 
 triple component that is used only for one target SPIR:

 How would existing toolchains that consume LLVM-IR for SPIR cope with the 
 fact that the Default address space is different for C++ and SYCL.
>>>
>>> High level languages differences doesn't matter for toolchains consuming 
>>> LLVM IR - it can python, D or SYCL. Toolchains are assuming that LLVM IR 
>>> follows the sematic defined in SPIR-1.2 document - 
>>> https://www.khronos.org/registry/SPIR/specs/spir_spec-1.2.pdf.
>>
>> I can't understand what you mean by "doesn't matter"?
>
> LLVM has it's own sematic which toolchains rely on. Toolchains consuming LLVM 
> IR doesn't know if this LLVM IR was emitted by C++ compiler or written 
> manually - they can rely only on LLVM IR semantic defined by 
> https://llvm.org/docs/LangRef.html.
>
>> If you compiler from C++ you get one address space as `Default` and if you 
>> compile from SYCL you get a different one for the same target - how do you 
>> expect the toolchain consuming the IR to handle that?
>
> Technically clang changes SPIR target mapping for Default address space only 
> for `sycldevice` environment component of the target triple, so it doesn't 
> depend on the input language i.e. Default is mapped to the same LLVM address 
> space for C++ and SYCL.

If you are suggesting to add SYCL as a component for other languages supported 
by clang this deserves a separate review probably with different reviewers and 
a wider discussion with the community.

>> FYI, the document is no longer describing the current SPIR target adequately 
>> as implementation deviated quite a bit from the original documentation.
>
> This is unfortunate. Do you know if there are any plans to provide up-to-date 
> documentation? It's critical for non-clang front-ends targeting SPIR-V format.

I am not aware of any plan. FYI SPIR has not been added or designed for SPIR-V. 
It is only used for SPIR-V as a workaround by some external projects but it is 
not the only use case even if perhaps an important one for the community.

 Why is changing of `the address space map necessary for SPIR but not the 
 other targets?
>>>
>>> The main reason is the difference in handling Default address space in C++ 
>>> for OpenCL mode and SYCL. C++ for OpenCL doesn't always deduce address 
>>> space and there are cases when Default is used and SPIR target maps it AS 0 
>>> (equivalent of SPIR-V Function storage class). This lead to inconsistencies 
>>> like reported here: https://bugs.llvm.org/show_bug.cgi?id=45472.
>>>
>>> SYCL doesn't deduce language address space at all relies on mapping Default 
>>> in LLVM AS equivalent of SPIR-V generic.
>>>
>>> NOTE: other GPU targets like AMDGPU and NVPTX do the same i.e. maps Default 
>>> language AS to LLVM IR AS equivalent of SPIR-V generic, so there is no need 
>>> to update. I believe SPIR target must apply the same mapping.
>>
>> Generic address space in Clang is a logical concept added for OpenCL to 
>> implement the following logical concept .
>> https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#the-generic-address-space
>>
>> Targets are allowed to map it to any physical address space (it is very 
>> reasonable to map it to `Default`) but it is only used for restricted use 
>> cases i.e. pointers or references.
>
> I agree with that, but I don't get how it's related to the mapping language 
> AS to LLVM AS.

Every language address space has its own semantic that should be mapped 
appropriately to LLVM IR to make sure the semantic is preserved.

OpenCL generic is a concept governed by OpenCL C spec cited above

  It can be used with pointer types and it represents a placeholder for any of 
the named address spaces - global, local or private. It signals that a pointer 
p

[PATCH] D95448: [flang][driver] Add support for `-J/-module-dir`

[Arnamoy B via Phabricator via cfe-commits]

arnamoy10 added a comment.

Sounds good to me, thanks for the help.  In the meantime I will work on the 
`fdefault-*` family of flags, which will be dependent on this patch I think.




Comment at: clang/include/clang/Driver/Options.td:4124
 def A_DASH : Joined<["-"], "A-">, Group;
-def J : JoinedOrSeparate<["-"], "J">, Flags<[RenderJoined]>, 
Group;
 def cpp : Flag<["-"], "cpp">, Group;

awarzynski wrote:
> There's no need to move this, is there? I feel that it's better to keep all 
> `gfortran` options together.
This needs to be moved, as we are using Aliases.  The way Aliases work is (in 
this order) (1) you create the base option (that 



Comment at: clang/include/clang/Driver/Options.td:1018
+  an USE statement.  The default is the current 
directory.}]>,Group;
+def module_dir : Separate<["-"], "module-dir">, 
Flags<[FlangOption,FC1Option]>, MetaVarName<"">, Alias;
 def dsym_dir : JoinedOrSeparate<["-"], "dsym-dir">,

tskeith wrote:
> It would be better to make `-module-dir` the main option and `-J` the alias. 
> `-J` is only there for gfortran compatibility, not because it is a good name 
> for the option.
Sure, we can do that.  I just chose -J to be default as it is easier to type 
for the user :)



Comment at: flang/lib/Frontend/CompilerInstance.cpp:29
+  semantics_(new Fortran::semantics::SemanticsContext(*(new  
Fortran::common::IntrinsicTypeDefaultKinds()),*(new 
common::LanguageFeatureControl()),
+ *allCookedSources_)) {
 

tskeith wrote:
> Why is `semantics_` a `shared_ptr` rather than a simple data member of  type 
> `SemanticsContext`? It's owned by only `CompilerInstance`, not shared.
> The same question probably applies to the other fields too.
No idea about this design decision.  I have not found any other DS that is 
"sharing" these pointers.  I can take them out.



Comment at: flang/lib/Frontend/CompilerInvocation.cpp:302
+
+void CompilerInvocation::setSemanticsOpts(Fortran::semantics::SemanticsContext 
&semaCtxt) {
+  auto &fortranOptions = fortranOpts();

awarzynski wrote:
> The argument is not needed here, is it? You could just write:
> ```
> auto &semaCtx = semanticsContext()
> ```
> Or am I missing something?
`semanticsContext_` belongs to `CompilerInstance`, not `CompilerInvocation`, so 
unfortunately that is not possible.



Comment at: flang/test/Flang-Driver/include-module.f90:11
 ! RUN: not %flang-new -fsyntax-only -I %S/Inputs %s  2>&1 | FileCheck %s 
--check-prefix=SINGLEINCLUDE
+! RUN: not %flang-new -fsyntax-only -J %S/Inputs -I %S/Inputs/module-dir %s  
2>&1 | FileCheck %s --check-prefix=INCLUDED
+! RUN: not %flang-new -fsyntax-only -J %S/Inputs %s  2>&1 | FileCheck %s 
--check-prefix=SINGLEINCLUDE

awarzynski wrote:
> What about:
> *  `-J %S/Inputs -J %S/Inputs/module-dir` (i.e. `-J` + `-J`)
> * `-J %S/Inputs -module-dir %S/Inputs/module-dir` (i.e. `-J` + `-module-dir`)
> * `-module-dir %S/Inputs -J%S/Inputs/module-dir` (i.e. `-module-dir` + `-J`)
> * `-module-dir %S/Inputs -I%S/Inputs/module-dir` (.e. `-module-dir` + `-I`)
> 
> I appreciate that this is a bit tedious, but IMO it is worthwhile to add a 
> few more cases here to avoid any unpleasant breakage in the future. Also - 
> what should the relation between `-I` and `-J` be here? As in, which ought to 
> have higher priority? 
Done


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

https://reviews.llvm.org/D95448

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

[PATCH] D95849: [FileCheck] Default --allow-unused-prefixes to false

[Mircea Trofin via Phabricator via cfe-commits]

mtrofin added a comment.

In D95849#2535939 , @jhenderson wrote:

> I assume this now runs cleanly. If so, LGTM. Probably worth mentioning on the 
> mailing list thread too, so wrap up that conversation. By the way, did we 
> ever figure out how many of the failures were genuine bugs versus deliberate 
> isntances?

Except for the tests under  llvm/test/Transforms/Attributor/, which D94744 
 explicitly opts into allowing unused prefixes 
(and which @jdoerfert described as intentionally so), the rest (~1300) were 
bugs: i.e. unintentionally unused prefixes.

Out of them, a small handful were spelling mistakes (identified as such during 
code review by their authors) and fixed rather than removed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95849

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

[clang] 9a5dc01 - [clang][PATCH][NFC] Correct test case related to review D95482

[Melanie Blower via cfe-commits]

Author: Melanie Blower
Date: 2021-02-02T07:06:43-08:00
New Revision: 9a5dc01e4b65b15c73751f5b3d9273ea73533b5d

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

LOG: [clang][PATCH][NFC] Correct test case related to review D95482

Added: 
clang/test/SemaCXX/pr48848.cpp

Modified: 
clang/test/SemaCXX/lambda-expressions.cpp

Removed: 




diff  --git a/clang/test/SemaCXX/lambda-expressions.cpp 
b/clang/test/SemaCXX/lambda-expressions.cpp
index 03bf13733d7b..22e0939379f5 100644
--- a/clang/test/SemaCXX/lambda-expressions.cpp
+++ b/clang/test/SemaCXX/lambda-expressions.cpp
@@ -1,8 +1,6 @@
 // RUN: %clang_cc1 -std=c++14 -Wno-unused-value -fsyntax-only -verify 
-verify=expected-cxx14 -fblocks %s
 // RUN: %clang_cc1 -std=c++17 -Wno-unused-value -fsyntax-only -verify -fblocks 
%s
-// RUN: %clang_cc1 -std=c++17 -fblocks -DSHOW_MS -Wno-unused-value 
-fms-compatibility -fdelayed-template-parsing -fsyntax-only -verify %s
 
-#ifndef SHOW_MS
 namespace std { class type_info; };
 
 namespace ExplicitCapture {
@@ -666,22 +664,3 @@ void Test() {
 
 }
 };
-
-#else
-template 
-void Decider(const RT &sp, ET &ep) {
-  [=](auto i) { ep[i] = sp[i + j]; };
-// expected-error@-1 {{use of undeclared identifier 'j'}}
-}
-
-template  void LS() {
-  int *ep;
-  Decider(5, ep);
-}
-
-void runChapter4()
-{
-  LS(); // expected-note {{in instantiation of}}
-}
-
-#endif

diff  --git a/clang/test/SemaCXX/pr48848.cpp b/clang/test/SemaCXX/pr48848.cpp
new file mode 100644
index ..064dbb137082
--- /dev/null
+++ b/clang/test/SemaCXX/pr48848.cpp
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -std=c++17 -fblocks -DSHOW_MS -Wno-unused-value 
-fms-compatibility -fdelayed-template-parsing -fsyntax-only -verify %s
+template 
+void Decider(const RT &sp, ET &ep) {
+  [=](auto i) { ep[i] = sp[i + j]; };
+  // expected-error@-1 {{use of undeclared identifier 'j'}}
+}
+
+template  void LS() {
+  int *ep;
+  Decider(5, ep);
+}
+
+void runChapter4() {
+  LS(); // expected-note {{in instantiation of}}
+}



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

[clang] 5bbf397 - [OpenCL] Add diagnostics for references to functions

[Anastasia Stulova via cfe-commits]

Author: Anastasia Stulova
Date: 2021-02-02T15:07:40Z
New Revision: 5bbf39704c2b70581d78a463f3c9d20b0eb7dcd5

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

LOG: [OpenCL] Add diagnostics for references to functions

Restrict use of references to functions as they can
result in non-conforming behavior.

Tags: #clang

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

Added: 
clang/test/SemaOpenCLCXX/references.cl

Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaType.cpp
clang/test/SemaOpenCLCXX/members.cl

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 67c59f3ca09a..d31cc76b04d1 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -8547,7 +8547,7 @@ def err_invalid_conversion_between_vector_and_integer : 
Error<
   "of 
diff erent size">;
 
 def err_opencl_function_pointer : Error<
-  "pointers to functions are not allowed">;
+  "%select{pointers|references}0 to functions are not allowed">;
 
 def err_opencl_taking_address_capture : Error<
   "taking address of a capture is not allowed">;

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index ef4947baf665..7da00cb598f4 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -6756,10 +6756,13 @@ static bool diagnoseOpenCLTypes(Scope *S, Sema &Se, 
Declarator &D,
 
   // OpenCL v1.0 s6.8.a.3: Pointers to functions are not allowed.
   if (!Se.getOpenCLOptions().isEnabled("__cl_clang_function_pointers")) {
-QualType NR = R;
-while (NR->isPointerType() || NR->isMemberFunctionPointerType()) {
-  if (NR->isFunctionPointerType() || NR->isMemberFunctionPointerType()) {
-Se.Diag(D.getIdentifierLoc(), diag::err_opencl_function_pointer);
+QualType NR = R.getCanonicalType();
+while (NR->isPointerType() || NR->isMemberFunctionPointerType() ||
+   NR->isReferenceType()) {
+  if (NR->isFunctionPointerType() || NR->isMemberFunctionPointerType() ||
+  NR->isFunctionReferenceType()) {
+Se.Diag(D.getIdentifierLoc(), diag::err_opencl_function_pointer)
+<< NR->isReferenceType();
 D.setInvalidType();
 return false;
   }

diff  --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 4178024d1264..e24eb266dd5f 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -2091,7 +2091,7 @@ QualType Sema::BuildPointerType(QualType T,
 
   if (T->isFunctionType() && getLangOpts().OpenCL &&
   !getOpenCLOptions().isEnabled("__cl_clang_function_pointers")) {
-Diag(Loc, diag::err_opencl_function_pointer);
+Diag(Loc, diag::err_opencl_function_pointer) << /*pointer*/ 0;
 return QualType();
   }
 
@@ -2163,6 +2163,12 @@ QualType Sema::BuildReferenceType(QualType T, bool 
SpelledAsLValue,
   if (checkQualifiedFunction(*this, T, Loc, QFK_Reference))
 return QualType();
 
+  if (T->isFunctionType() && getLangOpts().OpenCL &&
+  !getOpenCLOptions().isEnabled("__cl_clang_function_pointers")) {
+Diag(Loc, diag::err_opencl_function_pointer) << /*reference*/ 1;
+return QualType();
+  }
+
   // In ARC, it is forbidden to build references to unqualified pointers.
   if (getLangOpts().ObjCAutoRefCount)
 T = inferARCLifetimeForPointee(*this, T, Loc, /*reference*/ true);
@@ -2889,6 +2895,12 @@ QualType Sema::BuildMemberPointerType(QualType T, 
QualType Class,
 return QualType();
   }
 
+  if (T->isFunctionType() && getLangOpts().OpenCL &&
+  !getOpenCLOptions().isEnabled("__cl_clang_function_pointers")) {
+Diag(Loc, diag::err_opencl_function_pointer) << /*pointer*/ 0;
+return QualType();
+  }
+
   // Adjust the default free function calling convention to the default method
   // calling convention.
   bool IsCtorOrDtor =

diff  --git a/clang/test/SemaOpenCLCXX/members.cl 
b/clang/test/SemaOpenCLCXX/members.cl
index d561445eb8a2..855948f0615e 100644
--- a/clang/test/SemaOpenCLCXX/members.cl
+++ b/clang/test/SemaOpenCLCXX/members.cl
@@ -13,31 +13,13 @@ struct C {
 };
 
 typedef void (C::*p_t)(int);
-
-template  struct remove_reference { typedef T type; };
-template  struct remove_reference { typedef T type; };
-
-template 
-void templ_test() {
-  typename remove_reference::type *ptr;
 #ifndef FUNCPTREXT
-  //expected-error@-2{{pointers to functions are not allowed}}
+//expected-error@-2{{pointers to functions are not allowed}}
 #endif
-}
 
 void test() {
   void (C::*p)(int);
 #ifndef FUNCPTREXT
 //expected-error@-2{{pointers to functions are not allowed}}
-#endif
-
-  p_t p1;
-#ifndef FUNCPTREXT
-//expected-error@-2{{pointers to func

[PATCH] D95442: [OpenCL] Add diagnostics for references to functions

[Anastasia Stulova via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG5bbf39704c2b: [OpenCL] Add diagnostics for references to 
functions (authored by Anastasia).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95442

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/SemaOpenCLCXX/members.cl
  clang/test/SemaOpenCLCXX/references.cl

Index: clang/test/SemaOpenCLCXX/references.cl
===
--- /dev/null
+++ clang/test/SemaOpenCLCXX/references.cl
@@ -0,0 +1,46 @@
+//RUN: %clang_cc1 %s -cl-std=clc++ -verify -fsyntax-only
+//RUN: %clang_cc1 %s -cl-std=clc++ -verify -fsyntax-only -DFPTREXT
+
+#ifdef FPTREXT
+#pragma OPENCL EXTENSION __cl_clang_function_pointers : enable
+#endif // FPTREXT
+
+// References to functions are not allowed.
+struct myclass {
+//FIXME: Here we provide incorrect diagnostic.
+  void (&mem)(); //expected-error{{reference to function type cannot have '__generic' qualifier}}
+};
+
+void (&glob)();
+#ifndef FPTREXT
+//expected-error@-2{{references to functions are not allowed}}
+#else
+//expected-error@-4{{declaration of reference variable 'glob' requires an initializer}}
+#endif // FPTREXT
+
+using ref2fct_t = void (&)();
+#ifndef FPTREXT
+//expected-error@-2{{references to functions are not allowed}}
+#endif // FPTREXT
+typedef void (&ref2fct_t)();
+#ifndef FPTREXT
+//expected-error@-2{{references to functions are not allowed}}
+#endif // FPTREXT
+
+void test(void (&par)()) {
+#ifndef FPTREXT
+//expected-error@-2{{references to functions are not allowed}}
+#endif // FPTREXT
+  void (&loc)();
+#ifndef FPTREXT
+//expected-error@-2{{references to functions are not allowed}}
+#else
+//expected-error@-4{{declaration of reference variable 'loc' requires an initializer}}
+#endif // FPTREXT
+
+  void (*&ref2fptr)();
+#ifndef FPTREXT
+//expected-error@-2{{pointers to functions are not allowed}}
+#endif // FPTREXT
+//expected-error@-4{{declaration of reference variable 'ref2fptr' requires an initializer}}
+}
Index: clang/test/SemaOpenCLCXX/members.cl
===
--- clang/test/SemaOpenCLCXX/members.cl
+++ clang/test/SemaOpenCLCXX/members.cl
@@ -13,31 +13,13 @@
 };
 
 typedef void (C::*p_t)(int);
-
-template  struct remove_reference { typedef T type; };
-template  struct remove_reference { typedef T type; };
-
-template 
-void templ_test() {
-  typename remove_reference::type *ptr;
 #ifndef FUNCPTREXT
-  //expected-error@-2{{pointers to functions are not allowed}}
+//expected-error@-2{{pointers to functions are not allowed}}
 #endif
-}
 
 void test() {
   void (C::*p)(int);
 #ifndef FUNCPTREXT
 //expected-error@-2{{pointers to functions are not allowed}}
-#endif
-
-  p_t p1;
-#ifndef FUNCPTREXT
-//expected-error@-2{{pointers to functions are not allowed}}
-#endif
-
-  templ_test();
-#ifndef FUNCPTREXT
-//expected-note@-2{{in instantiation of function template specialization}}
 #endif
 }
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -2091,7 +2091,7 @@
 
   if (T->isFunctionType() && getLangOpts().OpenCL &&
   !getOpenCLOptions().isEnabled("__cl_clang_function_pointers")) {
-Diag(Loc, diag::err_opencl_function_pointer);
+Diag(Loc, diag::err_opencl_function_pointer) << /*pointer*/ 0;
 return QualType();
   }
 
@@ -2163,6 +2163,12 @@
   if (checkQualifiedFunction(*this, T, Loc, QFK_Reference))
 return QualType();
 
+  if (T->isFunctionType() && getLangOpts().OpenCL &&
+  !getOpenCLOptions().isEnabled("__cl_clang_function_pointers")) {
+Diag(Loc, diag::err_opencl_function_pointer) << /*reference*/ 1;
+return QualType();
+  }
+
   // In ARC, it is forbidden to build references to unqualified pointers.
   if (getLangOpts().ObjCAutoRefCount)
 T = inferARCLifetimeForPointee(*this, T, Loc, /*reference*/ true);
@@ -2889,6 +2895,12 @@
 return QualType();
   }
 
+  if (T->isFunctionType() && getLangOpts().OpenCL &&
+  !getOpenCLOptions().isEnabled("__cl_clang_function_pointers")) {
+Diag(Loc, diag::err_opencl_function_pointer) << /*pointer*/ 0;
+return QualType();
+  }
+
   // Adjust the default free function calling convention to the default method
   // calling convention.
   bool IsCtorOrDtor =
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -6756,10 +6756,13 @@
 
   // OpenCL v1.0 s6.8.a.3: Pointers to functions are not allowed.
   if (!Se.getOpenCLOptions().isEnabled("__cl_clang_function_pointers")) {
-QualType NR = R;
-while (NR->isPointerType() || NR->isMemberFunctionPointerType(

[PATCH] D95849: [FileCheck] Default --allow-unused-prefixes to false

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

Just to be clear here: Only the small handful where a spelling mistake was 
fixed were actually bugs. All other unused check prefixes were there for 
convenience, and are now casualties of this unnecessary crusade. I regret not 
speaking out against this at the time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95849

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

[clang] 903a153 - Ensure that the matcher is instantiated

[Stephen Kelly via cfe-commits]

Author: Stephen Kelly
Date: 2021-02-02T15:12:39Z
New Revision: 903a153409b8640aac30fa0b46b9a99ad90fe786

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

LOG: Ensure that the matcher is instantiated

Fix issue diagnosed by Windows linker.

Added: 


Modified: 
clang/lib/ASTMatchers/ASTMatchersInternal.cpp

Removed: 




diff  --git a/clang/lib/ASTMatchers/ASTMatchersInternal.cpp 
b/clang/lib/ASTMatchers/ASTMatchersInternal.cpp
index 6ebc72d450fe..b20a60425661 100644
--- a/clang/lib/ASTMatchers/ASTMatchersInternal.cpp
+++ b/clang/lib/ASTMatchers/ASTMatchersInternal.cpp
@@ -733,6 +733,7 @@ const internal::VariadicDynCastAllOfMatcher
 typeAliasTemplateDecl;
 const internal::VariadicAllOfMatcher decl;
 const internal::VariadicDynCastAllOfMatcher 
decompositionDecl;
+const internal::VariadicDynCastAllOfMatcher bindingDecl;
 const internal::VariadicDynCastAllOfMatcher
 linkageSpecDecl;
 const internal::VariadicDynCastAllOfMatcher namedDecl;



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

[PATCH] D95739: [ASTMatchers] Add matchers for decomposition decls

[Stephen Kelly via Phabricator via cfe-commits]

steveire added a comment.

In D95739#2536515 , @thakis wrote:

> Looks like this doesn't link on windows: 
> http://45.33.8.238/win/32481/step_4.txt

Thanks, should be fixed now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95739

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

[PATCH] D69560: [clang-tidy] Add 'bugprone-easily-swappable-parameters' check

[Whisperity via Phabricator via cfe-commits]

whisperity marked 3 inline comments as done.
whisperity added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:402-403
+
+// Unfortunately, undersquiggly highlights are for some reason chewed up
+// and not respected by diagnostics from Clang-Tidy. :(
+diag(First->getLocation(), "the first parameter in the range is '%0'",

whisperity wrote:
> aaron.ballman wrote:
> > whisperity wrote:
> > > aaron.ballman wrote:
> > > > Can you post a screenshot of what you mean?
> > > Given
> > > 
> > > ```
> > > Diag << SourceRange{First->getSourceRange().getBegin(), 
> > > Last->getSourceRange().getEnd()};
> > > ```
> > > 
> > > The diagnostic is still produced with only a `^` at the original 
> > > `diag(Location)`, ignoring the fed `SourceRange`:
> > > 
> > > ```
> > > /home/whisperity/LLVM/Build/../llvm-project/clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:21:18:
> > >  warning: 3 adjacent parameters of 'redeclChain' of similar type ('int') 
> > > are easily swapped by mistake [bugprone-easily-swappable-parameters]
> > > void redeclChain(int I, int J, int K) {}
> > >  ^
> > > ```
> > > 
> > > Instead of putting all the squigglies in as the range-location highlight, 
> > > like how `Sema` can diagnose:
> > > 
> > > ```
> > > /home/whisperity/LLVM/Build/../llvm-project/clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:21:18:
> > >  warning: 3 adjacent parameters of 'redeclChain' of similar type ('int') 
> > > are easily swapped by mistake [bugprone-easily-swappable-parameters]
> > > void redeclChain(int I, int J, int K) {}
> > >  ^~~
> > > ```
> > > 
> > > I would not want to put additional note tags in an otherwise already 
> > > verbose output.
> > > 
> > > Back in 2019 I was investigating this issue specifically for another 
> > > checker I was working on, but hit the wall... Somewhere deep inside where 
> > > Tidy diagnostic stuff is translated and consumed to Clang stuff, it goes 
> > > away. It shouldn't, because there are statements that seemingly copy the 
> > > `Diag.Ranges` array over, but it still does not come out.
> > > 
> > > ... EDIT: I found [[ 
> > > http://lists.llvm.org/pipermail/cfe-dev/2019-October/063676.html | the 
> > > relevant mailing list post ]].
> > > ... EDIT: I found the relevant mailing list post.
> > 
> > Oh wow, I had no idea! That's a rather unfortunate bug. :-(
> Speaking of bugs, shall I put it up on Bugzilla, or see if anyone reported 
> already? Would require me digging into that "where are the data structures 
> copied" kind of thing to figure it out again.
Nevermind, this is worth [[ http://bugzilla.llvm.org/show_bug.cgi?id=49000 | a 
bug report ]] just so we can track it in the proper location.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69560

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

[PATCH] D69560: [clang-tidy] Add 'bugprone-easily-swappable-parameters' check

[Stephen Kelly via Phabricator via cfe-commits]

steveire added a comment.

I haven't read through all the comments, but the word 'easily' implies 
'desirable'. This check seems to be for finding params which are undesirably 
swappable, right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69560

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

[PATCH] D95776: [OpenCL] Add macro definitions of OpenCL C 3.0 features

[Anton Zabaznov via Phabricator via cfe-commits]

azabaznov added inline comments.



Comment at: clang/lib/Basic/Targets.cpp:743
+  // Assume compiling for FULL profile
+  Builder.defineMacro("__opencl_c_int64");
 }

Anastasia wrote:
> Btw we could add the other feature macros for earlier versions too but I 
> guess it makes code more complicated?
Yes, this will complicate things: we decided to generate a warning if any of 
core features is unsupported, right? So making OpenCL C 3.0 features as core in 
OpenCL C 2.0 will result in this kind of warning; distinguishing these features 
among the set of core functionality may require workarounds in clang, so let's 
keep them in headers only for OpenCL C 2.0.



Comment at: clang/lib/Headers/opencl-c.h:17161
+#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200)
+#undef __opencl_c_pipes
+#undef __opencl_c_generic_address_space

svenvh wrote:
> Anastasia wrote:
> > Looping in @svenvh  - I don't mind if we define those macros in headers for 
> > OpenCL 2.0. The only concern is that if we `undef` them here we will end up 
> > with different behavior between `-finclude-default-header` and 
> > `-fdeclare-opencl-builtins`. I would suggest not to `undef` them because it 
> > is better if we have coherency. Alternatively we could also add a third 
> > header with undefs that can be included at the end for both but it seems to 
> > make things even more complicated.
> > 
> > FYI `__opencl_c_int64` is already added for all OpenCL versions.
> > The only concern is that if we undef them here we will end up with 
> > different behavior between -finclude-default-header and 
> > -fdeclare-opencl-builtins
> 
> This is a valid point.  Doing the undefs only in `opencl-c.h` will lead to a 
> problem similar to https://reviews.llvm.org/D91429 .
> 
> A third header just for the undefs sounds like a bit of an overkill indeed, 
> although having duplication isn't great either.  Not sure what's best to be 
> honest.
My idea was just to temporary define features for built-ins and enums 
definitions as this is the only place where these macros may be useful for 
OpenCL C 2.0. However, I don't have any strong concerns if these macros will 
remain defined.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95776

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

[PATCH] D78979: OpenCL: Include builtin header by default

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.
Herald added a reviewer: jansvoboda11.

@arsenm I would like to see if we can finalize this patch soon. Do you think 
you will have a capacity for this in the next weeks? Otherwise I would be happy 
to help too.

It looks in a good shape, we just need to decide if we go ahead with the new 
flag you are adding or reuse `-nostdinc`. Do you have any preference yourself?


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

https://reviews.llvm.org/D78979

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

[PATCH] D69560: [clang-tidy] Add 'bugprone-easily-swappable-parameters' check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:402-403
+
+// Unfortunately, undersquiggly highlights are for some reason chewed up
+// and not respected by diagnostics from Clang-Tidy. :(
+diag(First->getLocation(), "the first parameter in the range is '%0'",

whisperity wrote:
> whisperity wrote:
> > aaron.ballman wrote:
> > > whisperity wrote:
> > > > aaron.ballman wrote:
> > > > > Can you post a screenshot of what you mean?
> > > > Given
> > > > 
> > > > ```
> > > > Diag << SourceRange{First->getSourceRange().getBegin(), 
> > > > Last->getSourceRange().getEnd()};
> > > > ```
> > > > 
> > > > The diagnostic is still produced with only a `^` at the original 
> > > > `diag(Location)`, ignoring the fed `SourceRange`:
> > > > 
> > > > ```
> > > > /home/whisperity/LLVM/Build/../llvm-project/clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:21:18:
> > > >  warning: 3 adjacent parameters of 'redeclChain' of similar type 
> > > > ('int') are easily swapped by mistake 
> > > > [bugprone-easily-swappable-parameters]
> > > > void redeclChain(int I, int J, int K) {}
> > > >  ^
> > > > ```
> > > > 
> > > > Instead of putting all the squigglies in as the range-location 
> > > > highlight, like how `Sema` can diagnose:
> > > > 
> > > > ```
> > > > /home/whisperity/LLVM/Build/../llvm-project/clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:21:18:
> > > >  warning: 3 adjacent parameters of 'redeclChain' of similar type 
> > > > ('int') are easily swapped by mistake 
> > > > [bugprone-easily-swappable-parameters]
> > > > void redeclChain(int I, int J, int K) {}
> > > >  ^~~
> > > > ```
> > > > 
> > > > I would not want to put additional note tags in an otherwise already 
> > > > verbose output.
> > > > 
> > > > Back in 2019 I was investigating this issue specifically for another 
> > > > checker I was working on, but hit the wall... Somewhere deep inside 
> > > > where Tidy diagnostic stuff is translated and consumed to Clang stuff, 
> > > > it goes away. It shouldn't, because there are statements that seemingly 
> > > > copy the `Diag.Ranges` array over, but it still does not come out.
> > > > 
> > > > ... EDIT: I found [[ 
> > > > http://lists.llvm.org/pipermail/cfe-dev/2019-October/063676.html | the 
> > > > relevant mailing list post ]].
> > > > ... EDIT: I found the relevant mailing list post.
> > > 
> > > Oh wow, I had no idea! That's a rather unfortunate bug. :-(
> > Speaking of bugs, shall I put it up on Bugzilla, or see if anyone reported 
> > already? Would require me digging into that "where are the data structures 
> > copied" kind of thing to figure it out again.
> Nevermind, this is worth [[ http://bugzilla.llvm.org/show_bug.cgi?id=49000 | 
> a bug report ]] just so we can track it in the proper location.
If you don't mind doing that effort, it'd be appreciated! Even if you don't 
root cause the issue, having the report (or pinging an existing one) is still 
useful.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:10
+
+void declaration(int Param, int Other); // NO-WARN: No chance to change this 
function.
+

whisperity wrote:
> aaron.ballman wrote:
> > whisperity wrote:
> > > aaron.ballman wrote:
> > > > I think this is a case where we could warn when the declaration is 
> > > > outside of a system header (perhaps as an option).
> > > > 
> > > > Thinking about it a bit more, declarations and definitions provide a 
> > > > novel way to get another kind of swap:
> > > > ```
> > > > void func(int x, int y);
> > > > void func(int y, int x) {} // Oops, the swap was probably not 
> > > > intentional
> > > > ```
> > > > which may or may not be interesting for a check (or its heuristics).
> > > I gave this some thought. It is a very good idea, but I believe not for 
> > > //this// check, but D20689. What do you think of that? Maybe simply 
> > > saying "call site v. function node that was called" could be extended 
> > > with a completely analogous, string distance function based "function 
> > > definition node v. redecl chain" case.
> > Hmmm, my impression is that this check is fundamentally about *parameter* 
> > ordering whereas D20689 is about *argument* ordering. Given that the 
> > example is about the ordering of parameters and doesn't have anything to do 
> > with call sites, I kind of think the functionality would be better in a 
> > parameter-oriented check.
> > 
> > That said, it doesn't feel entirely natural to add it to this check because 
> > this check is about parameters that are easily swappable *at call sites*, 
> > and this situation is not exactly that. However, it could probably be 
> > argued that it is appropriate to add it to this check given that swapped 
> 

[PATCH] D69560: [clang-tidy] Add 'bugprone-easily-swappable-parameters' check

[Whisperity via Phabricator via cfe-commits]

whisperity added a comment.

In D69560#2536570 , @steveire wrote:

> I haven't read through all the comments, but the word 'easily' implies 
> 'desirable'. This check seems to be for finding params which are undesirably 
> swappable, right?

The `easily` was to mean that the swap can be done with little effort (i.e. "in 
an easy fashion"?) and by accident. We want to find function signatures where 
that is the case, yes. TL;DR: //"This function will be misused by a careless 
client, please try designing a better interface!"//


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69560

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

[PATCH] D95778: [OpenCL] Introduce new language options for OpenCL keywords.

[Anton Zabaznov via Phabricator via cfe-commits]

azabaznov added a comment.

In D95778#2536266 , @Anastasia wrote:

>> LGTM, but perhaps you can add a test that has each keyword disabled?
>
> FYI we currently already test that `pipe` and `generic` are valid for OpenCL 
> 2.0 and invalid for OpenCL < 2.0. Or do you mean different kind of tests? In 
> OpenCL 3.0 we will have to set the new `LangOpts` fields based on the values 
> of `OpenCLOptions`  but my guess is that is going to be added in the 
> subsequent patches...

Yes, I believe there are tests already for earlier versions. Should I mark this 
change as NFC?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95778

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

[PATCH] D69560: [clang-tidy] Add 'bugprone-easily-swappable-parameters' check

[Whisperity via Phabricator via cfe-commits]

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



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:10
+
+void declaration(int Param, int Other); // NO-WARN: No chance to change this 
function.
+

aaron.ballman wrote:
> whisperity wrote:
> > aaron.ballman wrote:
> > > whisperity wrote:
> > > > aaron.ballman wrote:
> > > > > I think this is a case where we could warn when the declaration is 
> > > > > outside of a system header (perhaps as an option).
> > > > > 
> > > > > Thinking about it a bit more, declarations and definitions provide a 
> > > > > novel way to get another kind of swap:
> > > > > ```
> > > > > void func(int x, int y);
> > > > > void func(int y, int x) {} // Oops, the swap was probably not 
> > > > > intentional
> > > > > ```
> > > > > which may or may not be interesting for a check (or its heuristics).
> > > > I gave this some thought. It is a very good idea, but I believe not for 
> > > > //this// check, but D20689. What do you think of that? Maybe simply 
> > > > saying "call site v. function node that was called" could be extended 
> > > > with a completely analogous, string distance function based "function 
> > > > definition node v. redecl chain" case.
> > > Hmmm, my impression is that this check is fundamentally about *parameter* 
> > > ordering whereas D20689 is about *argument* ordering. Given that the 
> > > example is about the ordering of parameters and doesn't have anything to 
> > > do with call sites, I kind of think the functionality would be better in 
> > > a parameter-oriented check.
> > > 
> > > That said, it doesn't feel entirely natural to add it to this check 
> > > because this check is about parameters that are easily swappable *at call 
> > > sites*, and this situation is not exactly that. However, it could 
> > > probably be argued that it is appropriate to add it to this check given 
> > > that swapped parameters between the declaration and the definition are 
> > > likely to result in swapped arguments at call sites.
> > > 
> > > Don't feel obligated to add this functionality to this check (or invent a 
> > > new check), though.
> > It just seems incredibly easier to put it into the other check, as that 
> > deals with names. But yes, then it would be a bit weird for the "suspicious 
> > call argument" check to say something about the definition... This check 
> > (and the relevant Core Guideline) was originally meant to consider **only** 
> > types (this is something I'll have to emphasise more in the research paper 
> > too!). Everything that considers //names// is only for making the check 
> > less noisy and make the actually emitted results more useful. However, I 
> > feel we should //specifically// not rely on the names and the logic too 
> > much.
> > 
> > But(!) your suggestion is otherwise a good idea. I am not sure if the 
> > previous research (with regards to names) consider the whole "forward 
> > declaration" situation, even where they did analysis for C projects, not 
> > just Java.
> > However, I feel we should specifically not rely on the names and the logic 
> > too much.
> 
> I agree, to a point. I don't think the basic check logic should be 
> name-sensitive, but I do think we need to rely on names to tweak the 
> true/false positive/negative ratios. I think most of the time when we're 
> relying on names should wind up being configuration options so that users can 
> tune the algorithm to their needs.
> 
> We could put the logic into the suspicious call argument check with roughly 
> the same logic -- the call site looks like it has potentially swapped 
> arguments because the function redeclaration chain (which includes the 
> function definition, as that's also a declaration) has inconsistent parameter 
> names. So long as the diagnostic appears on the call site, and then refers 
> back to the inconsistent declarations, it could probably work. However, I 
> think it'd be a bit strange to diagnose the call site because the user of the 
> API didn't really do anything wrong (and they may not even be able to change 
> the declaration or the definition where the problem really lives).
But wait... suppose there is a project A, which sees the header for `f(int x, 
int y)` and has a call `f(y, x)`. That will be diagnosed. But if project A is 
only a client of `f`, it should be highly unlikely that project A has the 
//definition// of `f` in their tree, right? So people of A will not get the 
warning for that. Only what is part of the compilation process will be part of 
the analysis process.

Similarly to how this check matches **only** function definitions, and never a 
prototype. The latter one would have bazillion of warnings from every header 
ever, with the user not having a chance to fix it anyways.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llv

[PATCH] D69560: [clang-tidy] Add 'bugprone-easily-swappable-parameters' check

[Whisperity via Phabricator via cfe-commits]

whisperity added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:402-403
+
+// Unfortunately, undersquiggly highlights are for some reason chewed up
+// and not respected by diagnostics from Clang-Tidy. :(
+diag(First->getLocation(), "the first parameter in the range is '%0'",

aaron.ballman wrote:
> whisperity wrote:
> > whisperity wrote:
> > > aaron.ballman wrote:
> > > > whisperity wrote:
> > > > > aaron.ballman wrote:
> > > > > > Can you post a screenshot of what you mean?
> > > > > Given
> > > > > 
> > > > > ```
> > > > > Diag << SourceRange{First->getSourceRange().getBegin(), 
> > > > > Last->getSourceRange().getEnd()};
> > > > > ```
> > > > > 
> > > > > The diagnostic is still produced with only a `^` at the original 
> > > > > `diag(Location)`, ignoring the fed `SourceRange`:
> > > > > 
> > > > > ```
> > > > > /home/whisperity/LLVM/Build/../llvm-project/clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:21:18:
> > > > >  warning: 3 adjacent parameters of 'redeclChain' of similar type 
> > > > > ('int') are easily swapped by mistake 
> > > > > [bugprone-easily-swappable-parameters]
> > > > > void redeclChain(int I, int J, int K) {}
> > > > >  ^
> > > > > ```
> > > > > 
> > > > > Instead of putting all the squigglies in as the range-location 
> > > > > highlight, like how `Sema` can diagnose:
> > > > > 
> > > > > ```
> > > > > /home/whisperity/LLVM/Build/../llvm-project/clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:21:18:
> > > > >  warning: 3 adjacent parameters of 'redeclChain' of similar type 
> > > > > ('int') are easily swapped by mistake 
> > > > > [bugprone-easily-swappable-parameters]
> > > > > void redeclChain(int I, int J, int K) {}
> > > > >  ^~~
> > > > > ```
> > > > > 
> > > > > I would not want to put additional note tags in an otherwise already 
> > > > > verbose output.
> > > > > 
> > > > > Back in 2019 I was investigating this issue specifically for another 
> > > > > checker I was working on, but hit the wall... Somewhere deep inside 
> > > > > where Tidy diagnostic stuff is translated and consumed to Clang 
> > > > > stuff, it goes away. It shouldn't, because there are statements that 
> > > > > seemingly copy the `Diag.Ranges` array over, but it still does not 
> > > > > come out.
> > > > > 
> > > > > ... EDIT: I found [[ 
> > > > > http://lists.llvm.org/pipermail/cfe-dev/2019-October/063676.html | 
> > > > > the relevant mailing list post ]].
> > > > > ... EDIT: I found the relevant mailing list post.
> > > > 
> > > > Oh wow, I had no idea! That's a rather unfortunate bug. :-(
> > > Speaking of bugs, shall I put it up on Bugzilla, or see if anyone 
> > > reported already? Would require me digging into that "where are the data 
> > > structures copied" kind of thing to figure it out again.
> > Nevermind, this is worth [[ http://bugzilla.llvm.org/show_bug.cgi?id=49000 
> > | a bug report ]] just so we can track it in the proper location.
> If you don't mind doing that effort, it'd be appreciated! Even if you don't 
> root cause the issue, having the report (or pinging an existing one) is still 
> useful.
And I managed to post a broken link originally... Here's the right one: 
https://bugs.llvm.org/show_bug.cgi?id=49000


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69560

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

[PATCH] D95778: [OpenCL] Introduce new language options for OpenCL keywords.

[Anton Zabaznov via Phabricator via cfe-commits]

azabaznov added inline comments.



Comment at: clang/include/clang/Basic/LangOptions.def:218
 LANGOPT(OpenCLCPlusPlusVersion , 32, 0, "C++ for OpenCL version")
+LANGOPT(OpenCLGenericKeyword, 1, 0, "OpenCL generic keyword")
+LANGOPT(OpenCLPipeKeyword   , 1, 0, "OpenCL pipe keyword")

Anastasia wrote:
> Normally we use just a name of the feature, so perhaps:
> 
> OpenCLGenericKeyword -> OpenCLGenericAddressSpace
> OpenCLPipeKeyword -> OpenCLPipe
Ok, will change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95778

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

[PATCH] D95860: [clang][Frontend] Fix a crash in DiagnosticRenderer.

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

Please, also add a regression test for Haoxin Tu's reproducer.

  // RUN: %clang %s
  
  // expected warning
  volatile long a ( a .~b


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95860

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

[PATCH] D95871: [clang] Store the location for invalid type of a declarator.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
hokein added a reviewer: sammccall.
Herald added a subscriber: kristof.beyls.
hokein requested review of this revision.
Herald added a project: clang.

Prior to the patch, for an invalid type of declarator, the TInfo's location was
invalid. This patch would improve the tooling (syntax-tree) on handling broken
code.

see the following example:

  void test(undef);
  // before: ParmVarDecl > col:16 invalid 'int'
  // after: ParmVarDecl  col:16 invalid 'int'


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95871

Files:
  clang/lib/Sema/SemaType.cpp
  clang/test/AST/ast-dump-color.cpp
  clang/test/AST/ast-dump-invalid.cpp


Index: clang/test/AST/ast-dump-invalid.cpp
===
--- clang/test/AST/ast-dump-invalid.cpp
+++ clang/test/AST/ast-dump-invalid.cpp
@@ -52,10 +52,10 @@
 // CHECK:  | |-CXXRecordDecl {{.*}}  col:8 implicit struct 
Str
 // CHECK-NEXT: | `-CXXMethodDecl {{.*}}  col:11 invalid 
foo1 'double (double, int)'
 // CHECK-NEXT: |   |-ParmVarDecl {{.*}}  col:22 'double'
-// CHECK-NEXT: |   `-ParmVarDecl {{.*}} > col:36 
invalid 'int'
+// CHECK-NEXT: |   `-ParmVarDecl {{.*}}  col:36 invalid 'int'
 // CHECK-NEXT: `-CXXMethodDecl {{.*}} parent {{.*}}  
line:47:13 invalid foo1 'double (double, int)'
 // CHECK-NEXT:   |-ParmVarDecl {{.*}}  col:24 'double'
-// CHECK-NEXT:   |-ParmVarDecl {{.*}} > col:38 invalid 
'int'
+// CHECK-NEXT:   |-ParmVarDecl {{.*}}  col:38 invalid 'int'
 // CHECK-NEXT:   `-CompoundStmt {{.*}} 
 // CHECK-NEXT: `-ReturnStmt {{.*}} 
 // CHECK-NEXT:   `-ImplicitCastExpr {{.*}}  'double' 

Index: clang/test/AST/ast-dump-color.cpp
===
--- clang/test/AST/ast-dump-color.cpp
+++ clang/test/AST/ast-dump-color.cpp
@@ -92,7 +92,7 @@
 //CHECK: {{^}}[[Blue]]|-[[RESET]][[GREEN]]CXXRecordDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]line:28:1[[RESET]], 
[[Yellow]]line:30:1[[RESET]]> [[Yellow]]line:28:8[[RESET]] struct[[CYAN]] 
Invalid[[RESET]] definition
 //CHECK: {{^}}[[Blue]]| |-[[RESET]][[GREEN]]CXXRecordDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:1[[RESET]], 
[[Yellow]]col:8[[RESET]]> [[Yellow]]col:8[[RESET]] implicit referenced 
struct[[CYAN]] Invalid[[RESET]]
 //CHECK: {{^}}[[Blue]]| 
|-[[RESET]][[GREEN]]CXXConstructorDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]line:29:3[[RESET]], 
[[Yellow]]col:42[[RESET]]> [[Yellow]]col:29[[RESET]] invalid[[CYAN]] 
Invalid[[RESET]] [[Green]]'void (int)'[[RESET]]
-//CHECK: {{^}}[[Blue]]| | |-[[RESET]][[GREEN]]ParmVarDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:37[[RESET]], [[Yellow]][[RESET]]> [[Yellow]]col:42[[RESET]] invalid [[Green]]'int'[[RESET]]
+//CHECK: {{^}}[[Blue]]| | |-[[RESET]][[GREEN]]ParmVarDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:37[[RESET]]> 
[[Yellow]]col:42[[RESET]] invalid [[Green]]'int'[[RESET]]
 //CHECK: {{^}}[[Blue]]| | `-[[RESET]][[BLUE]]NoInlineAttr[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:18[[RESET]]>
 //CHECK: {{^}}[[Blue]]| 
|-[[RESET]][[GREEN]]CXXConstructorDecl[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]line:28:8[[RESET]]> 
[[Yellow]]col:8[[RESET]] implicit used constexpr[[CYAN]] Invalid[[RESET]] 
[[Green]]'void () noexcept'[[RESET]] inline
 //CHECK: {{^}}[[Blue]]| | 
`-[[RESET]][[MAGENTA]]CompoundStmt[[RESET]][[Yellow]] 
0x{{[0-9a-fA-F]*}}[[RESET]] <[[Yellow]]col:8[[RESET]]>
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -5656,8 +5656,7 @@
 
   assert(!T.isNull() && "T must not be null at the end of this function");
   if (D.isInvalidType())
-return Context.getTrivialTypeSourceInfo(T);
-
+return Context.getTrivialTypeSourceInfo(T, D.getEndLoc());
   return GetTypeSourceInfoForDeclarator(state, T, TInfo);
 }
 


Index: clang/test/AST/ast-dump-invalid.cpp
===
--- clang/test/AST/ast-dump-invalid.cpp
+++ clang/test/AST/ast-dump-invalid.cpp
@@ -52,10 +52,10 @@
 // CHECK:  | |-CXXRecordDecl {{.*}}  col:8 implicit struct Str
 // CHECK-NEXT: | `-CXXMethodDecl {{.*}}  col:11 invalid foo1 'double (double, int)'
 // CHECK-NEXT: |   |-ParmVarDecl {{.*}}  col:22 'double'
-// CHECK-NEXT: |   `-ParmVarDecl {{.*}} > col:36 invalid 'int'
+// CHECK-NEXT: |   `-ParmVarDecl {{.*}}  col:36 invalid 'int'
 // CHECK-NEXT: `-CXXMethodDecl {{.*}} parent {{.*}}  line:47:13 invalid foo1 'double (double, int)'
 // CHECK-NEXT:   |-ParmVarDecl {{.*}}  col:24 'double'
-// CHECK-NEXT:   |-ParmVarDecl {{.*}} > col:38 invalid 'int'
+// CHECK-NEXT:   |-ParmVarDecl {{.*}}  col:38 invalid 'int'
 // CHECK-NEXT:   `-CompoundStmt {{.*}} 
 // CHECK-NEXT: `-ReturnStmt {{.*}} 
 // CHECK-NEXT:   `-ImplicitCastExpr {{.*}}  'double' 
Index: clang

[PATCH] D95872: [clang][Arm] Fix handling of -Wa,-march=

[David Spickett via Phabricator via cfe-commits]

DavidSpickett created this revision.
Herald added subscribers: danielkiss, kristof.beyls.
DavidSpickett requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This fixes Bugzilla #48894 for Arm, where it
was reported that -Wa,-march was not being handled
by the integrated assembler.

This was previously fixed for -Wa,-mthumb by
parsing the argument in ToolChain::ComputeLLVMTriple
instead of CollectArgsForIntegratedAssembler.
It has to be done in the former because the Triple
is read only by the time we get to the latter.

Previously only mcpu would work via -Wa but only because
"-target-cpu" is it's own option to cc1, which we were
able to modify. Target architecture is part of "-target-triple".

This change applies the same workaround to -march and cleans up
handling of -Wa,-mcpu at the same time. There were some
places where we were not using the last instance of an argument.

The existing -Wa,-mthumb code was doing this correctly,
so I've just added tests to confirm that.

Now the same rules will apply to -Wa,-march/-mcpu as would
if you just passed them to the compiler:

- -Wa/-Xassembler options only apply to assembly files.
- Architecture derived from mcpu beats any march options.
- When there are multiple mcpu or multiple march, the last one wins.
- If there is a compiler option and an assembler option of the same type, we 
prefer the one that fits the input type.
- If there is an applicable mcpu option but it is overruled by an march, the 
cpu value is still used for the "-target-cpu" cc1 option.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D95872

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/test/Driver/arm-target-as-march-mcpu.s
  clang/test/Driver/arm-target-as-mthumb.s

Index: clang/test/Driver/arm-target-as-mthumb.s
===
--- clang/test/Driver/arm-target-as-mthumb.s
+++ clang/test/Driver/arm-target-as-mthumb.s
@@ -5,12 +5,16 @@
 // RUN: %clang -target armv7a-linux-gnueabi -### -c -mthumb %s 2>&1 | \
 // RUN: FileCheck -check-prefix=TRIPLE-ARM %s
 // RUN: %clang -target armv7a-linux-gnueabi -### -c -Wa,-mthumb \
-// RUN: %S/Inputs/wildcard1.c  2>&1 | FileCheck -check-prefix=TRIPLE-ARM %s
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck -check-prefix=TRIPLE-ARM %s
+// RUN: %clang -target armv7a-linux-gnueabi -### -c -Wa,-mcpu=cortex-a8,-mthumb \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck -check-prefix=TRIPLE-ARM %s
 
 // TRIPLE-ARM: "-triple" "armv7-unknown-linux-gnueabi"
 
 // RUN: %clang -target armv7a-linux-gnueabi -### -c -Wa,-mthumb %s 2>&1 | \
 // RUN: FileCheck -check-prefix=TRIPLE-THUMB %s
+// RUN: %clang -target armv7a-linux-gnueabi -### -c -Wa,-mcpu=cortex-a8,-mthumb %s 2>&1 | \
+// RUN: FileCheck -check-prefix=TRIPLE-THUMB %s
 // RUN: %clang -target armv7a-linux-gnueabi -### -c -Xassembler -mthumb %s \
 // RUN: 2>&1 | FileCheck -check-prefix=TRIPLE-THUMB %s
 
Index: clang/test/Driver/arm-target-as-march-mcpu.s
===
--- /dev/null
+++ clang/test/Driver/arm-target-as-march-mcpu.s
@@ -0,0 +1,101 @@
+/// These tests make sure that options passed to the assembler
+/// via -Wa or -Xassembler are applied correctly to assembler inputs.
+/// Also we check that the same priority rules apply to compiler and
+/// assembler options.
+
+/// Sanity check how the options behave when passed to the compiler
+// RUN: %clang -target arm-linux-gnueabi -### -c -march=armv7-a %s 2>&1 | \
+// RUN: FileCheck -check-prefix=TRIPLE-ARMV7 %s
+// RUN: %clang -target arm-linux-gnueabi -### -c -march=armv7-a+crc %s 2>&1 | \
+// RUN: FileCheck -check-prefix=TRIPLE-ARMV7 --check-prefix=EXT-CRC %s
+
+/// -Wa/-Xassembler doesn't apply to non assembly files
+// RUN: %clang -target arm-linux-gnueabi -### -c -Wa,-march=armv7-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck -check-prefix=TRIPLE-ARMV4 %s
+// RUN: %clang -target arm-linux-gnueabi -### -c -Xassembler -march=armv7-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck -check-prefix=TRIPLE-ARMV4 %s
+
+/// -Wa/-Xassembler does apply to assembler input
+// RUN: %clang -target arm-linux-gnueabi -### -c -Wa,-march=armv7-a %s 2>&1 | \
+// RUN: FileCheck -check-prefix=TRIPLE-ARMV7 %s
+// RUN: %clang -target arm-linux-gnueabi -### -c -Wa,-march=armv7-a+crc %s 2>&1 | \
+// RUN: FileCheck -check-prefix=TRIPLE-ARMV7 --check-prefix=EXT-CRC %s
+// RUN: %clang -target arm-linux-gnueabi -### -c -Xassembler -march=armv7-a %s 2>&1 | \
+// RUN: FileCheck -check-prefix=TRIPLE-ARMV7 %s
+// RUN: %clang -target arm-linux-gnueabi -### -c -Xassembler -march=armv7-a+crc %s 2>&1 | \
+// RUN: FileCheck -check-prefix=TRIPLE-ARMV7 --check-prefix=EXT-CRC %s
+
+/// Check that arch name is still canonicalised
+// RUN: %clang -target arm-linux-gnueabi -### -c -Wa,-march=armv7a %s 2>&1 | \
+// RUN: FileCheck -check-prefix=TRIPLE-ARMV7 %s
+// RUN: %clan

[PATCH] D95872: [clang][Arm] Fix handling of -Wa,-march=

[David Spickett via Phabricator via cfe-commits]

DavidSpickett added a comment.

Bug link: https://bugs.llvm.org/show_bug.cgi?id=48894


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95872

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

[PATCH] D95872: [clang][Arm] Fix handling of -Wa,-march=

[David Spickett via Phabricator via cfe-commits]

DavidSpickett added reviewers: ostannard, nickdesaulniers.
DavidSpickett added inline comments.



Comment at: clang/lib/Driver/ToolChain.cpp:753
 : tools::arm::getARMTargetCPU(MCPU, MArch, Triple);
 StringRef Suffix =
   tools::arm::getLLVMArchSuffixForARM(CPU, MArch, Triple);

Suffix originally set here, from any compiler options.



Comment at: clang/lib/Driver/ToolChain.cpp:807
+// over -Wa,-march. Which matches the compiler behaviour.
+Suffix = tools::arm::getLLVMArchSuffixForARM(WaMCPU, WaMArch, Triple);
+  }

Then we override that if we're using the assembler and have -Wa options.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95872

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

[PATCH] D78979: OpenCL: Include builtin header by default

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D78979#2536590 , @Anastasia wrote:

> @arsenm I would like to see if we can finalize this patch soon. Do you think 
> you will have a capacity for this in the next weeks? Otherwise I would be 
> happy to help too.

I don't think I'll have time soon, you can take over

> It looks in a good shape, we just need to decide if we go ahead with the new 
> flag you are adding or reuse `-nostdinc`. Do you have any preference yourself?

Not really sure. No real preference


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

https://reviews.llvm.org/D78979

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

[PATCH] D69560: [clang-tidy] Add 'bugprone-easily-swappable-parameters' check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:10
+
+void declaration(int Param, int Other); // NO-WARN: No chance to change this 
function.
+

whisperity wrote:
> aaron.ballman wrote:
> > whisperity wrote:
> > > aaron.ballman wrote:
> > > > whisperity wrote:
> > > > > aaron.ballman wrote:
> > > > > > I think this is a case where we could warn when the declaration is 
> > > > > > outside of a system header (perhaps as an option).
> > > > > > 
> > > > > > Thinking about it a bit more, declarations and definitions provide 
> > > > > > a novel way to get another kind of swap:
> > > > > > ```
> > > > > > void func(int x, int y);
> > > > > > void func(int y, int x) {} // Oops, the swap was probably not 
> > > > > > intentional
> > > > > > ```
> > > > > > which may or may not be interesting for a check (or its heuristics).
> > > > > I gave this some thought. It is a very good idea, but I believe not 
> > > > > for //this// check, but D20689. What do you think of that? Maybe 
> > > > > simply saying "call site v. function node that was called" could be 
> > > > > extended with a completely analogous, string distance function based 
> > > > > "function definition node v. redecl chain" case.
> > > > Hmmm, my impression is that this check is fundamentally about 
> > > > *parameter* ordering whereas D20689 is about *argument* ordering. Given 
> > > > that the example is about the ordering of parameters and doesn't have 
> > > > anything to do with call sites, I kind of think the functionality would 
> > > > be better in a parameter-oriented check.
> > > > 
> > > > That said, it doesn't feel entirely natural to add it to this check 
> > > > because this check is about parameters that are easily swappable *at 
> > > > call sites*, and this situation is not exactly that. However, it could 
> > > > probably be argued that it is appropriate to add it to this check given 
> > > > that swapped parameters between the declaration and the definition are 
> > > > likely to result in swapped arguments at call sites.
> > > > 
> > > > Don't feel obligated to add this functionality to this check (or invent 
> > > > a new check), though.
> > > It just seems incredibly easier to put it into the other check, as that 
> > > deals with names. But yes, then it would be a bit weird for the 
> > > "suspicious call argument" check to say something about the definition... 
> > > This check (and the relevant Core Guideline) was originally meant to 
> > > consider **only** types (this is something I'll have to emphasise more in 
> > > the research paper too!). Everything that considers //names// is only for 
> > > making the check less noisy and make the actually emitted results more 
> > > useful. However, I feel we should //specifically// not rely on the names 
> > > and the logic too much.
> > > 
> > > But(!) your suggestion is otherwise a good idea. I am not sure if the 
> > > previous research (with regards to names) consider the whole "forward 
> > > declaration" situation, even where they did analysis for C projects, not 
> > > just Java.
> > > However, I feel we should specifically not rely on the names and the 
> > > logic too much.
> > 
> > I agree, to a point. I don't think the basic check logic should be 
> > name-sensitive, but I do think we need to rely on names to tweak the 
> > true/false positive/negative ratios. I think most of the time when we're 
> > relying on names should wind up being configuration options so that users 
> > can tune the algorithm to their needs.
> > 
> > We could put the logic into the suspicious call argument check with roughly 
> > the same logic -- the call site looks like it has potentially swapped 
> > arguments because the function redeclaration chain (which includes the 
> > function definition, as that's also a declaration) has inconsistent 
> > parameter names. So long as the diagnostic appears on the call site, and 
> > then refers back to the inconsistent declarations, it could probably work. 
> > However, I think it'd be a bit strange to diagnose the call site because 
> > the user of the API didn't really do anything wrong (and they may not even 
> > be able to change the declaration or the definition where the problem 
> > really lives).
> But wait... suppose there is a project A, which sees the header for `f(int x, 
> int y)` and has a call `f(y, x)`. That will be diagnosed. But if project A is 
> only a client of `f`, it should be highly unlikely that project A has the 
> //definition// of `f` in their tree, right? So people of A will not get the 
> warning for that. Only what is part of the compilation process will be part 
> of the analysis process.
> 
> Similarly to how this check matches **only** function definitions, and never 
> a prototype. The latter one would have bazillion of warnings from every 
> header ever, with the user not having a chance to fix i

[PATCH] D69560: [clang-tidy] Add 'bugprone-easily-swappable-parameters' check

[Whisperity via Phabricator via cfe-commits]

whisperity added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:10
+
+void declaration(int Param, int Other); // NO-WARN: No chance to change this 
function.
+

aaron.ballman wrote:
> whisperity wrote:
> > aaron.ballman wrote:
> > > whisperity wrote:
> > > > aaron.ballman wrote:
> > > > > whisperity wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > I think this is a case where we could warn when the declaration 
> > > > > > > is outside of a system header (perhaps as an option).
> > > > > > > 
> > > > > > > Thinking about it a bit more, declarations and definitions 
> > > > > > > provide a novel way to get another kind of swap:
> > > > > > > ```
> > > > > > > void func(int x, int y);
> > > > > > > void func(int y, int x) {} // Oops, the swap was probably not 
> > > > > > > intentional
> > > > > > > ```
> > > > > > > which may or may not be interesting for a check (or its 
> > > > > > > heuristics).
> > > > > > I gave this some thought. It is a very good idea, but I believe not 
> > > > > > for //this// check, but D20689. What do you think of that? Maybe 
> > > > > > simply saying "call site v. function node that was called" could be 
> > > > > > extended with a completely analogous, string distance function 
> > > > > > based "function definition node v. redecl chain" case.
> > > > > Hmmm, my impression is that this check is fundamentally about 
> > > > > *parameter* ordering whereas D20689 is about *argument* ordering. 
> > > > > Given that the example is about the ordering of parameters and 
> > > > > doesn't have anything to do with call sites, I kind of think the 
> > > > > functionality would be better in a parameter-oriented check.
> > > > > 
> > > > > That said, it doesn't feel entirely natural to add it to this check 
> > > > > because this check is about parameters that are easily swappable *at 
> > > > > call sites*, and this situation is not exactly that. However, it 
> > > > > could probably be argued that it is appropriate to add it to this 
> > > > > check given that swapped parameters between the declaration and the 
> > > > > definition are likely to result in swapped arguments at call sites.
> > > > > 
> > > > > Don't feel obligated to add this functionality to this check (or 
> > > > > invent a new check), though.
> > > > It just seems incredibly easier to put it into the other check, as that 
> > > > deals with names. But yes, then it would be a bit weird for the 
> > > > "suspicious call argument" check to say something about the 
> > > > definition... This check (and the relevant Core Guideline) was 
> > > > originally meant to consider **only** types (this is something I'll 
> > > > have to emphasise more in the research paper too!). Everything that 
> > > > considers //names// is only for making the check less noisy and make 
> > > > the actually emitted results more useful. However, I feel we should 
> > > > //specifically// not rely on the names and the logic too much.
> > > > 
> > > > But(!) your suggestion is otherwise a good idea. I am not sure if the 
> > > > previous research (with regards to names) consider the whole "forward 
> > > > declaration" situation, even where they did analysis for C projects, 
> > > > not just Java.
> > > > However, I feel we should specifically not rely on the names and the 
> > > > logic too much.
> > > 
> > > I agree, to a point. I don't think the basic check logic should be 
> > > name-sensitive, but I do think we need to rely on names to tweak the 
> > > true/false positive/negative ratios. I think most of the time when we're 
> > > relying on names should wind up being configuration options so that users 
> > > can tune the algorithm to their needs.
> > > 
> > > We could put the logic into the suspicious call argument check with 
> > > roughly the same logic -- the call site looks like it has potentially 
> > > swapped arguments because the function redeclaration chain (which 
> > > includes the function definition, as that's also a declaration) has 
> > > inconsistent parameter names. So long as the diagnostic appears on the 
> > > call site, and then refers back to the inconsistent declarations, it 
> > > could probably work. However, I think it'd be a bit strange to diagnose 
> > > the call site because the user of the API didn't really do anything wrong 
> > > (and they may not even be able to change the declaration or the 
> > > definition where the problem really lives).
> > But wait... suppose there is a project A, which sees the header for `f(int 
> > x, int y)` and has a call `f(y, x)`. That will be diagnosed. But if project 
> > A is only a client of `f`, it should be highly unlikely that project A has 
> > the //definition// of `f` in their tree, right? So people of A will not get 
> > the warning for that. Only what is part of the compilation process will be 
> > part of the analysis process.
> > 
> > Similarly to how this

[PATCH] D69560: [clang-tidy] Add 'bugprone-easily-swappable-parameters' check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp:10
+
+void declaration(int Param, int Other); // NO-WARN: No chance to change this 
function.
+

whisperity wrote:
> aaron.ballman wrote:
> > whisperity wrote:
> > > aaron.ballman wrote:
> > > > whisperity wrote:
> > > > > aaron.ballman wrote:
> > > > > > whisperity wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > I think this is a case where we could warn when the declaration 
> > > > > > > > is outside of a system header (perhaps as an option).
> > > > > > > > 
> > > > > > > > Thinking about it a bit more, declarations and definitions 
> > > > > > > > provide a novel way to get another kind of swap:
> > > > > > > > ```
> > > > > > > > void func(int x, int y);
> > > > > > > > void func(int y, int x) {} // Oops, the swap was probably not 
> > > > > > > > intentional
> > > > > > > > ```
> > > > > > > > which may or may not be interesting for a check (or its 
> > > > > > > > heuristics).
> > > > > > > I gave this some thought. It is a very good idea, but I believe 
> > > > > > > not for //this// check, but D20689. What do you think of that? 
> > > > > > > Maybe simply saying "call site v. function node that was called" 
> > > > > > > could be extended with a completely analogous, string distance 
> > > > > > > function based "function definition node v. redecl chain" case.
> > > > > > Hmmm, my impression is that this check is fundamentally about 
> > > > > > *parameter* ordering whereas D20689 is about *argument* ordering. 
> > > > > > Given that the example is about the ordering of parameters and 
> > > > > > doesn't have anything to do with call sites, I kind of think the 
> > > > > > functionality would be better in a parameter-oriented check.
> > > > > > 
> > > > > > That said, it doesn't feel entirely natural to add it to this check 
> > > > > > because this check is about parameters that are easily swappable 
> > > > > > *at call sites*, and this situation is not exactly that. However, 
> > > > > > it could probably be argued that it is appropriate to add it to 
> > > > > > this check given that swapped parameters between the declaration 
> > > > > > and the definition are likely to result in swapped arguments at 
> > > > > > call sites.
> > > > > > 
> > > > > > Don't feel obligated to add this functionality to this check (or 
> > > > > > invent a new check), though.
> > > > > It just seems incredibly easier to put it into the other check, as 
> > > > > that deals with names. But yes, then it would be a bit weird for the 
> > > > > "suspicious call argument" check to say something about the 
> > > > > definition... This check (and the relevant Core Guideline) was 
> > > > > originally meant to consider **only** types (this is something I'll 
> > > > > have to emphasise more in the research paper too!). Everything that 
> > > > > considers //names// is only for making the check less noisy and make 
> > > > > the actually emitted results more useful. However, I feel we should 
> > > > > //specifically// not rely on the names and the logic too much.
> > > > > 
> > > > > But(!) your suggestion is otherwise a good idea. I am not sure if the 
> > > > > previous research (with regards to names) consider the whole "forward 
> > > > > declaration" situation, even where they did analysis for C projects, 
> > > > > not just Java.
> > > > > However, I feel we should specifically not rely on the names and the 
> > > > > logic too much.
> > > > 
> > > > I agree, to a point. I don't think the basic check logic should be 
> > > > name-sensitive, but I do think we need to rely on names to tweak the 
> > > > true/false positive/negative ratios. I think most of the time when 
> > > > we're relying on names should wind up being configuration options so 
> > > > that users can tune the algorithm to their needs.
> > > > 
> > > > We could put the logic into the suspicious call argument check with 
> > > > roughly the same logic -- the call site looks like it has potentially 
> > > > swapped arguments because the function redeclaration chain (which 
> > > > includes the function definition, as that's also a declaration) has 
> > > > inconsistent parameter names. So long as the diagnostic appears on the 
> > > > call site, and then refers back to the inconsistent declarations, it 
> > > > could probably work. However, I think it'd be a bit strange to diagnose 
> > > > the call site because the user of the API didn't really do anything 
> > > > wrong (and they may not even be able to change the declaration or the 
> > > > definition where the problem really lives).
> > > But wait... suppose there is a project A, which sees the header for 
> > > `f(int x, int y)` and has a call `f(y, x)`. That will be diagnosed. But 
> > > if project A is only a client of `f`, it should be highly unlikely that 
> > > project A has the //definition// of `f` in their 

[clang] eb3426a - [AIX] Improve option processing for mabi=vec-extabi and mabi=vec=defaul

[Zarko Todorovski via cfe-commits]

Author: Zarko Todorovski
Date: 2021-02-02T10:59:21-05:00
New Revision: eb3426a528d5b3cbbb54aee662a779f2067fc9db

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

LOG: [AIX] Improve option processing for mabi=vec-extabi and mabi=vec=defaul

Opening this revision to better address comments by @hubert.reinterpretcast in 
https://reviews.llvm.org/rGcaaaebcde462

Reviewed By: hubert.reinterpretcast

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/CodeGen/altivec.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 431f534c38fe..e2b9dc29868a 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4669,23 +4669,15 @@ void Clang::ConstructJob(Compilation &C, const 
JobAction &JA,
 }
   }
 
-  if (Triple.isOSAIX() && Args.hasArg(options::OPT_maltivec)) {
-if (Args.getLastArg(options::OPT_mabi_EQ_vec_extabi)) {
-  CmdArgs.push_back("-mabi=vec-extabi");
-} else {
-  D.Diag(diag::err_aix_default_altivec_abi);
-}
-  }
-
   if (Arg *A = Args.getLastArg(options::OPT_mabi_EQ_vec_extabi,
options::OPT_mabi_EQ_vec_default)) {
 if (!Triple.isOSAIX())
   D.Diag(diag::err_drv_unsupported_opt_for_target)
   << A->getSpelling() << RawTriple.str();
-if (A->getOption().getID() == options::OPT_mabi_EQ_vec_default)
-  D.Diag(diag::err_aix_default_altivec_abi);
 if (A->getOption().getID() == options::OPT_mabi_EQ_vec_extabi)
   CmdArgs.push_back("-mabi=vec-extabi");
+else
+  D.Diag(diag::err_aix_default_altivec_abi);
   }
 
   if (Arg *A = Args.getLastArg(options::OPT_Wframe_larger_than_EQ)) {

diff  --git a/clang/test/CodeGen/altivec.c b/clang/test/CodeGen/altivec.c
index d69c34d82190..86b570f15d08 100644
--- a/clang/test/CodeGen/altivec.c
+++ b/clang/test/CodeGen/altivec.c
@@ -6,9 +6,6 @@
 // RUN: %clang_cc1 -target-feature +altivec -mabi=vec-extabi -target-cpu pwr8 
-triple powerpc64-unknown-aix -emit-llvm %s -o - | FileCheck %s 
--check-prefixes=CHECK,CHECK-BE
 // RUN: not %clang_cc1 -target-feature +altivec -mabi=vec-default -target-cpu 
pwr8 -triple powerpc-unknown-aix -emit-llvm %s 2>&1 | FileCheck %s 
--check-prefix=AIX-ERROR
 // RUN: not %clang_cc1 -target-feature +altivec -mabi=vec-default -target-cpu 
pwr8 -triple powerpc64-unknown-aix -emit-llvm %s 2>&1 | FileCheck %s 
--check-prefix=AIX-ERROR
-
-// RUN: not %clang -S -emit-llvm -maltivec -mcpu=pwr8 -target 
powerpc-unknown-aix %s 2>&1 | FileCheck %s --check-prefix=AIX-ERROR
-// RUN: not %clang -S -emit-llvm -maltivec -mcpu=pwr8 -target 
powerpc64-unknown-aix %s 2>&1 | FileCheck %s --check-prefix=AIX-ERROR 
 // RUN: %clang -S -emit-llvm -maltivec -mabi=vec-extabi -mcpu=pwr8 -target 
powerpc-unknown-aix %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
 // RUN: %clang -S -emit-llvm -maltivec -mabi=vec-extabi -mcpu=pwr8 -target 
powerpc64-unknown-aix %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
 // RUN: not %clang -S -emit-llvm -maltivec -mabi=vec-default -mcpu=pwr8 
-triple powerpc-unknown-aix -emit-llvm %s 2>&1 | FileCheck %s 
--check-prefix=AIX-ERROR



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