[PATCH] D144510: [clang-tidy] improve readability-identifier-naming hungarian options test

[Piotr Zegar 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 rG3f6a8d52d645: [clang-tidy] improve 
readability-identifier-naming hungarian options test (authored by amurzeau, 
committed by PiotrZSL).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144510

Files:
  
clang-tools-extra/test/clang-tidy/checkers/readability/Inputs/identifier-naming/hungarian-notation2/.clang-tidy
  
clang-tools-extra/test/clang-tidy/checkers/readability/identifier-naming-hungarian-notation-cfgfile.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability/identifier-naming-hungarian-notation-cfgfile.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/readability/identifier-naming-hungarian-notation-cfgfile.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/readability/identifier-naming-hungarian-notation-cfgfile.cpp
@@ -57,159 +57,159 @@
 public:
   static int ClassMemberCase;
   // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: invalid case style for class member 'ClassMemberCase' [readability-identifier-naming]
-  // CHECK-FIXES: {{^}}  static int iClassMemberCase;
+  // CHECK-FIXES: {{^}}  static int custiClassMemberCase;
 
   char const ConstantMemberCase = 0;
   // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: invalid case style for constant member 'ConstantMemberCase' [readability-identifier-naming]
-  // CHECK-FIXES: {{^}}  char const cConstantMemberCase = 0;
+  // CHECK-FIXES: {{^}}  char const custcConstantMemberCase = 0;
 
   void MyFunc1(const int ConstantParameterCase);
   // CHECK-MESSAGES: :[[@LINE-1]]:26: warning: invalid case style for constant parameter 'ConstantParameterCase' [readability-identifier-naming]
-  // CHECK-FIXES: {{^}}  void MyFunc1(const int iConstantParameterCase);
+  // CHECK-FIXES: {{^}}  void MyFunc1(const int custiConstantParameterCase);
 
   void MyFunc2(const int* ConstantPointerParameterCase);
   // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: invalid case style for pointer parameter 'ConstantPointerParameterCase' [readability-identifier-naming]
-  // CHECK-FIXES: {{^}}  void MyFunc2(const int* piConstantPointerParameterCase);
+  // CHECK-FIXES: {{^}}  void MyFunc2(const int* custpcustiConstantPointerParameterCase);
 
   static constexpr int ConstexprVariableCase = 123;
   // CHECK-MESSAGES: :[[@LINE-1]]:24: warning: invalid case style for constexpr variable 'ConstexprVariableCase' [readability-identifier-naming]
-  // CHECK-FIXES: {{^}}  static constexpr int iConstexprVariableCase = 123;
+  // CHECK-FIXES: {{^}}  static constexpr int custiConstexprVariableCase = 123;
 };
 
 const int GlobalConstantCase = 0;
 // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: invalid case style for global constant 'GlobalConstantCase' [readability-identifier-naming]
-// CHECK-FIXES: {{^}}const int iGlobalConstantCase = 0;
+// CHECK-FIXES: {{^}}const int custiGlobalConstantCase = 0;
 
 const int* GlobalConstantPointerCase = nullptr;
 // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: invalid case style for global pointer 'GlobalConstantPointerCase' [readability-identifier-naming]
-// CHECK-FIXES: {{^}}const int* piGlobalConstantPointerCase = nullptr;
+// CHECK-FIXES: {{^}}const int* custpcustiGlobalConstantPointerCase = nullptr;
 
 int* GlobalPointerCase = nullptr;
 // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: invalid case style for global pointer 'GlobalPointerCase' [readability-identifier-naming]
-// CHECK-FIXES: {{^}}int* piGlobalPointerCase = nullptr;
+// CHECK-FIXES: {{^}}int* custpcustiGlobalPointerCase = nullptr;
 
 int GlobalVariableCase = 0;
 // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: invalid case style for global variable 'GlobalVariableCase' [readability-identifier-naming]
-// CHECK-FIXES: {{^}}int iGlobalVariableCase = 0;
+// CHECK-FIXES: {{^}}int custiGlobalVariableCase = 0;
 
 void Func1(){
   int const LocalConstantCase = 3;
   // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: invalid case style for local constant 'LocalConstantCase' [readability-identifier-naming]
-  // CHECK-FIXES: {{^}}  int const iLocalConstantCase = 3;
+  // CHECK-FIXES: {{^}}  int const custiLocalConstantCase = 3;
 
   unsigned const ConstantCase = 1;
   // CHECK-MESSAGES: :[[@LINE-1]]:18: warning: invalid case style for local constant 'ConstantCase' [readability-identifier-naming]
-  // CHECK-FIXES: {{^}}  unsigned const uConstantCase = 1;
+  // CHECK-FIXES: {{^}}  unsigned const custuConstantCase = 1;
 
   int* const LocalConstantPointerCase = nullptr;
   // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: invalid case style for local constant pointer 'LocalConstantPointerCase' [readability-identifier-naming]
-  // CHECK-FIXES: {{^}}  int* const piLocalConstantPointerCase = nullptr;
+  // CHECK-FIXES: {{^}}  int* const custpcustiLocalConstantPointerCase = nullptr;
 
   int *LocalPointerCase = nullptr;
   // CHE

[PATCH] D144035: [SCEV] Ensure SCEV does not replace aliases with their aliasees

[Leonard Chan via Phabricator via cfe-commits]

leonardchan added a subscriber: reames.
leonardchan added a comment.

@reames let's continue the discussion here. What specific bits with the 
optimizer does this break? I'm not too familiar with SVEC. Prior to this, one 
thing I tried was instead just doing `Ops.push_back(GA)` and `getSCEV(GA)` but 
those seemed to result in infinite recursions last I checked probably because 
there's another pass attempting to resolve aliases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144035

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

[PATCH] D142224: [Support] Emulate SIGPIPE handling in raw_fd_ostream write for Windows

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: llvm/lib/Support/Windows/Signals.inc:834
+  int RetCode = (int)EP->ExceptionRecord->ExceptionCode;
+  if (RetCode == (0xE000 | EX_IOERR))
+return;

This patch seems to cause a self-build Werror regression.  The mask here is 
large enough to cause the RHS of this to be unsigned, so the comparison hits 
`-Wsign-compare`. See the example here https://godbolt.org/z/fa5q889jh


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142224

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

[PATCH] D144218: [Clang] [AVR] Fix USHRT_MAX for 16-bit int.

[Daniel Thornburgh via Phabricator via cfe-commits]

mysterymath updated this revision to Diff 500264.
mysterymath marked an inline comment as done.
mysterymath added a comment.

Update condition; move release note to AVR section.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144218

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Headers/limits.h
  clang/test/Headers/limits.cpp

Index: clang/test/Headers/limits.cpp
===
--- clang/test/Headers/limits.cpp
+++ clang/test/Headers/limits.cpp
@@ -3,14 +3,39 @@
 // RUN: %clang_cc1 -std=c++11 -ffreestanding -fsyntax-only -verify %s
 // RUN: %clang_cc1 -std=c17 -ffreestanding -fsyntax-only -verify -x c %s
 // RUN: %clang_cc1 -std=c2x -ffreestanding -fsyntax-only -verify -x c %s
+
+// Specifically test 16-bit int platforms.
+// RUN: %clang_cc1 -triple=avr -ffreestanding -fsyntax-only -verify -x c %s
+
 // expected-no-diagnostics
 
 #include 
 
+#if __cplusplus
+#define EXPR_TYPE_IS(EXPR, TYP) __is_same(__typeof(EXPR), TYP)
+#else
+#define EXPR_TYPE_IS(EXPR, TYP) _Generic(EXPR, TYP: 1, default: 0)
+#endif
+
 _Static_assert(SCHAR_MAX == -(SCHAR_MIN+1), "");
+_Static_assert(EXPR_TYPE_IS(SCHAR_MAX, int), "");
+#if SCHAR_MAX
+#endif
+
 _Static_assert(SHRT_MAX == -(SHRT_MIN+1), "");
+_Static_assert(EXPR_TYPE_IS(SHRT_MAX, int), "");
+#if SHRT_MAX
+#endif
+
 _Static_assert(INT_MAX == -(INT_MIN+1), "");
+_Static_assert(EXPR_TYPE_IS(INT_MAX, int), "");
+#if INT_MAX
+#endif
+
 _Static_assert(LONG_MAX == -(LONG_MIN+1L), "");
+_Static_assert(EXPR_TYPE_IS(LONG_MAX, long), "");
+#if LONG_MAX
+#endif
 
 _Static_assert(SCHAR_MAX == UCHAR_MAX/2, "");
 _Static_assert(SHRT_MAX == USHRT_MAX/2, "");
@@ -18,26 +43,84 @@
 _Static_assert(LONG_MAX == ULONG_MAX/2, "");
 
 _Static_assert(SCHAR_MIN == -SCHAR_MAX-1, "");
+_Static_assert(EXPR_TYPE_IS(SCHAR_MIN, int), "");
+#if SCHAR_MIN
+#endif
+
 _Static_assert(SHRT_MIN == -SHRT_MAX-1, "");
+_Static_assert(EXPR_TYPE_IS(SHRT_MIN, int), "");
+#if SHRT_MIN
+#endif
+
 _Static_assert(INT_MIN == -INT_MAX-1, "");
+_Static_assert(EXPR_TYPE_IS(INT_MIN, int), "");
+#if INT_MIN
+#endif
+
 _Static_assert(LONG_MIN == -LONG_MAX-1L, "");
+_Static_assert(EXPR_TYPE_IS(LONG_MIN, long), "");
+#if LONG_MIN
+#endif
 
 _Static_assert(UCHAR_MAX == (unsigned char)~0ULL, "");
+_Static_assert(UCHAR_MAX <= INT_MAX ?
+ EXPR_TYPE_IS(UCHAR_MAX, int) :
+ EXPR_TYPE_IS(UCHAR_MAX, unsigned int), "");
+#if UCHAR_MAX
+#endif
+
 _Static_assert(USHRT_MAX == (unsigned short)~0ULL, "");
+_Static_assert(USHRT_MAX <= INT_MAX ?
+ EXPR_TYPE_IS(USHRT_MAX, int) :
+ EXPR_TYPE_IS(USHRT_MAX, unsigned int), "");
+#if USHRT_MAX
+#endif
+
 _Static_assert(UINT_MAX == (unsigned int)~0ULL, "");
+_Static_assert(EXPR_TYPE_IS(UINT_MAX, unsigned int), "");
+#if UINT_MAX
+#endif
+
 _Static_assert(ULONG_MAX == (unsigned long)~0ULL, "");
+_Static_assert(EXPR_TYPE_IS(ULONG_MAX, unsigned long), "");
+#if ULONG_MAX
+#endif
 
 _Static_assert(MB_LEN_MAX >= 1, "");
+#if MB_LEN_MAX
+#endif
 
 _Static_assert(CHAR_BIT >= 8, "");
+#if CHAR_BIT
+#endif
 
 _Static_assert(CHAR_MIN == (((char)-1 < (char)0) ? -CHAR_MAX-1 : 0), "");
+_Static_assert(EXPR_TYPE_IS(CHAR_MIN, int), "");
+#if CHAR_MIN
+#endif
+
 _Static_assert(CHAR_MAX == (((char)-1 < (char)0) ? -(CHAR_MIN+1) : (char)~0ULL), "");
+_Static_assert(CHAR_MAX <= INT_MAX ?
+ EXPR_TYPE_IS(CHAR_MAX, int) :
+ EXPR_TYPE_IS(CHAR_MAX, unsigned int), "");
+#if CHAR_MAX
+#endif
 
 #if __STDC_VERSION__ >= 199901 || __cplusplus >= 201103L
 _Static_assert(LLONG_MAX == -(LLONG_MIN+1LL), "");
+_Static_assert(EXPR_TYPE_IS(LLONG_MAX, long long), "");
+#if LLONG_MAX
+#endif
+
 _Static_assert(LLONG_MIN == -LLONG_MAX-1LL, "");
+#if LLONG_MIN
+#endif
+_Static_assert(EXPR_TYPE_IS(LLONG_MIN, long long), "");
+
 _Static_assert(ULLONG_MAX == (unsigned long long)~0ULL, "");
+_Static_assert(EXPR_TYPE_IS(ULLONG_MAX, unsigned long long), "");
+#if ULLONG_MAX
+#endif
 #else
 int LLONG_MIN, LLONG_MAX, ULLONG_MAX; // Not defined.
 #endif
@@ -47,35 +130,61 @@
 #if __STDC_VERSION__ >= 202000L
 /* Validate the standard requirements. */
 _Static_assert(BOOL_WIDTH >= 1);
+#if BOOL_WIDTH
+#endif
 
 _Static_assert(CHAR_WIDTH == CHAR_BIT);
 _Static_assert(CHAR_WIDTH / CHAR_BIT == sizeof(char));
+#if CHAR_WIDTH
+#endif
 _Static_assert(SCHAR_WIDTH == CHAR_BIT);
 _Static_assert(SCHAR_WIDTH / CHAR_BIT == sizeof(signed char));
+#if SCHAR_WIDTH
+#endif
 _Static_assert(UCHAR_WIDTH == CHAR_BIT);
 _Static_assert(UCHAR_WIDTH / CHAR_BIT == sizeof(unsigned char));
+#if UCHAR_WIDTH
+#endif
 
 _Static_assert(USHRT_WIDTH >= 16);
 _Static_assert(USHRT_WIDTH / CHAR_BIT == sizeof(unsigned short));
+#if USHRT_WIDTH
+#endif
 _Static_assert(SHRT_WIDTH == USHRT_WIDTH);
 _Static_assert(SHRT_WIDTH / CHAR_BIT == sizeof(signed short));
+#if SHRT_WIDTH
+#endif
 
 _Static_assert(UINT_WIDTH >= 16);
 _Static_assert(UINT_WIDTH / CHAR_BIT == s

[PATCH] D144218: [Clang] [AVR] Fix USHRT_MAX for 16-bit int.

[Daniel Thornburgh via Phabricator via cfe-commits]

mysterymath added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:43-45
+- The definition of ``USHRT_MAX`` in the freestanding  no longer
+  overflows on AVR (where ``sizeof(unsigned int) == sizeof(unsigned short)``).
+  The type of ``USHRT_MAX`` on AVR is now ``unsigned int`` instead of ``int``,

aaron.ballman wrote:
> I'd be surprised if this actually has much of a chance to break people. I'd 
> probably put this under a new AVR section under `Target Specific Changes`, 
> WDYT?
SGTM; I was on the fence about this.



Comment at: clang/lib/Headers/limits.h:55
 #define UCHAR_MAX (__SCHAR_MAX__*2  +1)
-#define USHRT_MAX (__SHRT_MAX__ *2  +1)
+#if __SHRT_MAX__ * 2U + 1U <= __INT_MAX__
+#define USHRT_MAX (__SHRT_MAX__ * 2 + 1)

aaron.ballman wrote:
> Rather than do math here, WDYT about using the WIDTH macros? It seems like a 
> more direct comparison:
> ```
> #if __SHRT_WIDTH__ == __INT_WIDTH__
> #endif
> ```
> (This also makes me wonder if we have any targets where we need to do this 
> with `UCHAR_MAX` as well. IIRC, we only support `CHAR_BIT` == 8 and so we're 
> probably fine, but might as well double-check since we're fixing this kind of 
> mistake.)
> Rather than do math here, WDYT about using the WIDTH macros? It seems like a 
> more direct comparison:
Spent a few seconds proving always holds, and it does, so long as you have the 
2's complement ranges. Given that the C standard formalized this in 2x, and 
it's all Clang supports anyway, SGTM.

In Clang's TargetInfo, CharWidth  is hard coded to 8, so there's no way to have 
a uchar that won't fit into int at present. I did add a test for this though in 
the limits.cpp, so if such a target were added to the list to check in the RUN 
lines, it would break.
That being said, it probably *wouldn't* be added, as was the case with AVR; if 
AVR had run under that test, this issue would have been caught even with the 
original version at HEAD.



Comment at: clang/lib/Headers/limits.h:55
 #define UCHAR_MAX (__SCHAR_MAX__*2  +1)
-#define USHRT_MAX (__SHRT_MAX__ *2  +1)
+#if __SHRT_MAX__ * 2U + 1U <= __INT_MAX__
+#define USHRT_MAX (__SHRT_MAX__ * 2 + 1)

mysterymath wrote:
> aaron.ballman wrote:
> > Rather than do math here, WDYT about using the WIDTH macros? It seems like 
> > a more direct comparison:
> > ```
> > #if __SHRT_WIDTH__ == __INT_WIDTH__
> > #endif
> > ```
> > (This also makes me wonder if we have any targets where we need to do this 
> > with `UCHAR_MAX` as well. IIRC, we only support `CHAR_BIT` == 8 and so 
> > we're probably fine, but might as well double-check since we're fixing this 
> > kind of mistake.)
> > Rather than do math here, WDYT about using the WIDTH macros? It seems like 
> > a more direct comparison:
> Spent a few seconds proving always holds, and it does, so long as you have 
> the 2's complement ranges. Given that the C standard formalized this in 2x, 
> and it's all Clang supports anyway, SGTM.
> 
> In Clang's TargetInfo, CharWidth  is hard coded to 8, so there's no way to 
> have a uchar that won't fit into int at present. I did add a test for this 
> though in the limits.cpp, so if such a target were added to the list to check 
> in the RUN lines, it would break.
> That being said, it probably *wouldn't* be added, as was the case with AVR; 
> if AVR had run under that test, this issue would have been caught even with 
> the original version at HEAD.
> Rather than do math here, WDYT about using the WIDTH macros? It seems like a 
> more direct comparison:
> ```
> #if __SHRT_WIDTH__ == __INT_WIDTH__
> #endif
> ```
> (This also makes me wonder if we have any targets where we need to do this 
> with `UCHAR_MAX` as well. IIRC, we only support `CHAR_BIT` == 8 and so we're 
> probably fine, but might as well double-check since we're fixing this kind of 
> mistake.)





Comment at: clang/lib/Headers/limits.h:55
 #define UCHAR_MAX (__SCHAR_MAX__*2  +1)
-#define USHRT_MAX (__SHRT_MAX__ *2  +1)
+#define USHRT_MAX (__SHRT_MAX__ * 2U + 1U)
 #define UINT_MAX  (__INT_MAX__  *2U +1U)

aaron.ballman wrote:
> mysterymath wrote:
> > aaron.ballman wrote:
> > > mysterymath wrote:
> > > > aaron.ballman wrote:
> > > > > It's worth double-checking that this still gives the correct type for 
> > > > > the macro:
> > > > > 
> > > > > C2x 5.2.4.2.1p2: For all unsigned integer types for which  
> > > > > or  define a macro with suffix _WIDTH holding its width N, 
> > > > > there is a macro with suffix _MAX holding the maximal value 2N − 1 
> > > > > that is representable by the type and that has the same type as would 
> > > > > an expression that is an object of the corresponding type converted 
> > > > > according to the integer promotions. ...
> > > > Ah, thanks; it hadn't occurred to me that the type of the expression 
> > > > would be specified in the standard. It could be either `unsigned int` 
> > > > or `

[PATCH] D135495: [clang-tidy] handle exceptions properly in `ExceptionAnalyzer`

[Domján Dániel via Phabricator via cfe-commits]

isuckatcs added a comment.

I'm not sure if I can run clang targetting AArch64 on an X86 machine but I 
tried it regardless and I get compiler errors on startup, so I can't debug this 
issue at the moment. 
Besided that I don't know why it times out on that buildbot. The build job that 
is performed on every revision passed without any problems.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135495

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

[PATCH] D142224: [Support] Emulate SIGPIPE handling in raw_fd_ostream write for Windows

[Alexandre Ganea via Phabricator via cfe-commits]

aganea added inline comments.



Comment at: llvm/lib/Support/Windows/Signals.inc:834
+  int RetCode = (int)EP->ExceptionRecord->ExceptionCode;
+  if (RetCode == (0xE000 | EX_IOERR))
+return;

erichkeane wrote:
> This patch seems to cause a self-build Werror regression.  The mask here is 
> large enough to cause the RHS of this to be unsigned, so the comparison hits 
> `-Wsign-compare`. See the example here https://godbolt.org/z/fa5q889jh
Please see rG1d0a5f11c04e6ac4dab578b81d02eabb83b31428


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142224

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

[PATCH] D135495: [clang-tidy] handle exceptions properly in `ExceptionAnalyzer`

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D135495#4151238 , @isuckatcs wrote:

> I'm not sure if I can run clang targetting AArch64 on an X86 machine but I 
> tried it regardless and I get compiler errors on startup, so I can't debug 
> this issue at the moment. 
> Besided that I don't know why it times out on that buildbot. The build job 
> that is performed on every revision passed without any problems.

As long as you don't need the library (which, if you have a preprocessed file 
or a test, should absolutely not be necessary), you can just do the -cc1 option 
of -triple , or the non- -cc1 option of -target .

Both use basically the same options list, and that bot seems to be 
"aarch64-unknown-linux-gnu" (see under cmake-stage-1 the llvm host triple).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135495

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

[PATCH] D142224: [Support] Emulate SIGPIPE handling in raw_fd_ostream write for Windows

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: llvm/lib/Support/Windows/Signals.inc:834
+  int RetCode = (int)EP->ExceptionRecord->ExceptionCode;
+  if (RetCode == (0xE000 | EX_IOERR))
+return;

aganea wrote:
> erichkeane wrote:
> > This patch seems to cause a self-build Werror regression.  The mask here is 
> > large enough to cause the RHS of this to be unsigned, so the comparison 
> > hits `-Wsign-compare`. See the example here https://godbolt.org/z/fa5q889jh
> Please see rG1d0a5f11c04e6ac4dab578b81d02eabb83b31428
Wonderful, thanks!  Looks like our build system didn't get to that yet.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142224

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

[PATCH] D143560: clang-format.el: fix warnings

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added a comment.

In D143560#4149733 , @phst wrote:

> I'm not super familiar with the process either, but IIRC @sammccall or 
> @djasper have to merge this.

Anyone with commit access can do that.

In D143560#4147918 , @augfab wrote:

> Hi @phst , is anything left for me to do before this patch is merged?
> This is my first patch to LLVM so I'm not too familiar with the process.
> Thanks for your help 🙂

If you don't have commit access yourself, please post your name and email for 
the commit. Someone will come and commit it on your behalf.


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

https://reviews.llvm.org/D143560

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

[PATCH] D144748: [clang-tidy] Add bugprone-empty-catch check

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/EmptyCatchCheck.cpp:77
+void EmptyCatchCheck::registerMatchers(MatchFinder *Finder) {
+
+  auto AllowedNamedExceptionDecl =

Excessive newline.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/empty-catch.rst:169
+should be provided. If an exception type name in the list is caught in an
+empty catch statement, no warning will be raised. Default value: `` 
(empty).

Mistake in default value formatting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144748

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

[PATCH] D116182: [ASan] Moved optimized callbacks into a separate library.

[Brittany Blue Gaston via Phabricator via cfe-commits]

thetruestblue added inline comments.
Herald added a project: All.



Comment at: compiler-rt/lib/asan/CMakeLists.txt:198
+ARCHS ${ASAN_SUPPORTED_ARCH}
+OBJECT_LIBS RTAsan_static
+CFLAGS ${ASAN_CFLAGS}

Can you explain the motivation here?

RTAsan_static object library isn't built on Apple & Apple ASAN doesn't support 
static libraries. is there a reason why this was added to Apple that I'm 
missing?

I don't believe this actually builds anything on Apple platforms since no OS is 
passed and in add_compiler_rt_runtime no libnames get set.

Even the tests added are not-apple specific.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116182

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

[PATCH] D144537: [clang-format] Don't move qualifiers past pointers-to-member

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks accepted this revision.
HazardyKnusperkeks added a comment.

In D144537#4145545 , @MyDeveloperDay 
wrote:

> maybe we should cherry pick into 16?

+1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144537

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

[PATCH] D144748: [clang-tidy] Add bugprone-empty-catch check

[Piotr Zegar via Phabricator via cfe-commits]

PiotrZSL added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/empty-catch.rst:169
+should be provided. If an exception type name in the list is caught in an
+empty catch statement, no warning will be raised. Default value: `` 
(empty).

Eugene.Zelenko wrote:
> Mistake in default value formatting.
Yy, what mistake ? (empty) not needed, or something else should be used instead 
of `` ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144748

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

[PATCH] D144748: [clang-tidy] Add bugprone-empty-catch check

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone/empty-catch.rst:169
+should be provided. If an exception type name in the list is caught in an
+empty catch statement, no warning will be raised. Default value: `` 
(empty).

PiotrZSL wrote:
> Eugene.Zelenko wrote:
> > Mistake in default value formatting.
> Yy, what mistake ? (empty) not needed, or something else should be used 
> instead of `` ?
Sorry, I mistook (empty) as part of value. May be just say this in words to 
avoid such confusions?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144748

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

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

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast requested changes to this revision.
hubert.reinterpretcast added inline comments.
This revision now requires changes to proceed.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5251
 
+  if (Args.hasFlag(options::OPT_mroptr, options::OPT_mno_roptr, false)) {
+if (!Triple.isOSAIX())

This accepts `-mno-roptr` for other platforms despite having no semantic 
functionality (e.g., it does not move variables to a different section for ELF 
codegen).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144190

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

[PATCH] D139589: [clang][Fuchsia] Re-enable hwasan global instrumentation on hwasan multilibs

[Leonard Chan via Phabricator via cfe-commits]

leonardchan abandoned this revision.
leonardchan added a comment.

This was landed in 
https://reviews.llvm.org/rG4308166403b4c28b6db7094a4e202e42da6e28a8


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D139589

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

[PATCH] D144748: [clang-tidy] Add bugprone-empty-catch check

[Piotr Zegar via Phabricator via cfe-commits]

PiotrZSL updated this revision to Diff 500274.
PiotrZSL added a comment.

Fix review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144748

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/EmptyCatchCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/EmptyCatchCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone/empty-catch.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/bugprone/empty-catch.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone/empty-catch.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone/empty-catch.cpp
@@ -0,0 +1,101 @@
+// RUN: %check_clang_tidy -std=c++98-or-later %s bugprone-empty-catch %t -- \
+// RUN: -config="{CheckOptions: [{key: bugprone-empty-catch.AllowEmptyCatchForExceptions, value: '::SafeException;WarnException'}, \
+// RUN:  {key: bugprone-empty-catch.IgnoreCatchWithKeywords, value: '@IGNORE;@TODO'}]}"
+
+struct Exception {};
+struct SafeException {};
+struct WarnException : Exception {};
+
+int functionWithThrow()
+{
+try
+{
+throw 5;
+}
+catch(const Exception&)
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: empty catch statements hide issues, to handle exceptions appropriately, consider re-throwing, handling, or avoiding catch altogether [bugprone-empty-catch]
+{
+}
+catch(...)
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: empty catch statements hide issues, to handle exceptions appropriately, consider re-throwing, handling, or avoiding catch altogether [bugprone-empty-catch]
+{
+}
+return 0;
+}
+
+int functionWithHandling()
+{
+try
+{
+throw 5;
+}
+catch(const Exception&)
+{
+return 2;
+}
+catch(...)
+{
+return 1;
+}
+return 0;
+}
+
+int functionWithReThrow()
+{
+try
+{
+throw 5;
+}
+catch(...)
+{
+throw;
+}
+}
+
+int functionWithNewThrow()
+{
+try
+{
+throw 5;
+}
+catch(...)
+{
+throw Exception();
+}
+}
+
+void functionWithAllowedException()
+{
+try
+{
+
+}
+catch(const SafeException&)
+{
+}
+catch(WarnException)
+{
+}
+}
+
+void functionWithComment()
+{
+try
+{
+}
+catch(const Exception&)
+{
+// @todo: implement later, check case insensitive
+}
+}
+
+void functionWithComment2()
+{
+try
+{
+}
+catch(const Exception&)
+{
+// @IGNORE: relax its safe
+}
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -86,6 +86,7 @@
`bugprone-dangling-handle `_,
`bugprone-dynamic-static-initializers `_,
`bugprone-easily-swappable-parameters `_,
+   `bugprone-empty-catch `_,
`bugprone-exception-escape `_,
`bugprone-fold-init-type `_,
`bugprone-forward-declaration-namespace `_,
Index: clang-tools-extra/docs/clang-tidy/checks/bugprone/empty-catch.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone/empty-catch.rst
@@ -0,0 +1,170 @@
+.. title:: clang-tidy - bugprone-empty-catch
+
+bugprone-empty-catch
+
+
+Detects and suggests addressing issues with empty catch statements.
+
+.. code-block:: c++
+
+try
+{
+// Some code that can throw an exception
+}
+catch(const std::exception&)
+{
+}
+
+Having empty catch statements in a codebase can be a serious problem that
+developers should be aware of. Catch statements are used to handle exceptions
+that are thrown during program execution. When an exception is thrown, the
+program jumps to the nearest catch statement that matches the type of the
+exception.
+
+Empty catch statements, also known as "swallowing" exceptions, catch the
+exception but do nothing with it. This means that the exception is not handled
+properly, and the program continues to run as if nothing happened. This can
+lead to several issues, such as:
+
+* *Hidden Bugs*: If an exception is caught and ignored, it can lead to hidden
+  bugs that are difficult to diagnose and fix. The root cause of the problem
+  may not be apparent, and the program may continue to behave in unexpected
+  ways.
+
+* *Security Issues*: Ignoring exceptions can lead to security issues, such as
+  buffer overflows or null pointer dereferences. Hackers can exploit these
+  vulnerabilities to gain access to sensitive data or execute malicious code.
+
+

[clang] 44b391f - LanguageExtensions.rst: fix a typo in the `#pragma clang deprecated` example

[Fangrui Song via cfe-commits]

Author: Fangrui Song
Date: 2023-02-24T12:41:49-08:00
New Revision: 44b391fc473c3ea8ce5d6cefeac6c781060b398f

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

LOG: LanguageExtensions.rst: fix a typo in the `#pragma clang deprecated` 
example

Added: 


Modified: 
clang/docs/LanguageExtensions.rst

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 2d1b8af40bbb..2595b5de8f26 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -4665,7 +4665,7 @@ provide deprecation warnings for macro uses. For example:
#define MIN(x, y) x < y ? x : y
#pragma clang deprecated(MIN, "use std::min instead")
 
-   void min(int a, int b) {
+   int min(int a, int b) {
  return MIN(a, b); // warning: MIN is deprecated: use std::min instead
}
 



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

[PATCH] D144709: [clang-format] Improve west to east const

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added a comment.

In D144709#4149737 , 
@AlexanderHederstaf wrote:

> I tried to refactor QualifierAlignmentFixer to handle more types, notably 
> removing the *,&,&& requirement as e.g. const Foo did not work. To avoid 
> moving qualifiers too far, a test for "already east const" is introduced. 
> **However, to get the correct order for the east qualifiers Clang-Format must 
> be used twice.** I assume it's related to how fixes/replacements are handled. 
> Would you like to have a look and perhaps suggest any improvements?
>
> As it must be used twice, some tests related to volatile/const order fail, 
> but I noticed most of them would also fails previously if the type is not 
> simple.

Highlight by me. That is not acceptable, running the output of `clang-format` 
through `clang-format` shall not result in any change. In that case it's better 
to not touch it in any way.




Comment at: clang/lib/Format/QualifierAlignmentFixer.cpp:226
+
+  const bool IsEastQualifier = PreviousCheck && [PreviousCheck]() {
+if (PreviousCheck->is(tok::r_paren)) {

In the initial commit concerns were raised that `East` and `West` are 
westcentric terms and should not be used. Thus you should stick here to `Left` 
and `Right` the same terms we use in the configuration.



Comment at: clang/lib/Format/QualifierAlignmentFixer.cpp:228
+if (PreviousCheck->is(tok::r_paren)) {
+  return true;
+} else if (PreviousCheck->is(TT_TemplateCloser)) {

Could you add comments what kind of source code we would have here?



Comment at: clang/lib/Format/QualifierAlignmentFixer.cpp:229
+  return true;
+} else if (PreviousCheck->is(TT_TemplateCloser)) {
+  return PreviousCheck->MatchingParen->Previous->isNot(tok::kw_template);

No `else` after `return`.



Comment at: clang/lib/Format/QualifierAlignmentFixer.cpp:230
+} else if (PreviousCheck->is(TT_TemplateCloser)) {
+  return PreviousCheck->MatchingParen->Previous->isNot(tok::kw_template);
+} else if (PreviousCheck->isOneOf(TT_PointerOrReference, tok::identifier,

That may be null, or not?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144709

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

[PATCH] D144569: [Clang][OpenMP] Fix accessing of aligned arrays in offloaded target regions

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

doru1004 added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:2274
+  if (!IsByRef) {
+if ((Ctx.getTargetInfo().getTriple().isAMDGCN()) ||
+(Ctx.getTargetInfo().getTriple().isNVPTX())) {

jhuber6 wrote:
> Why does this handling need to be different between CPU and GPU offloading? 
> Strictly speaking, I'm not sure why we need the alignment type here since 
> we'd only get improper alignment on primitive types. So I figured that it 
> should only care about the alignment of the type itself in all cases. Maybe 
> someone can correct me on that.
Are you saying that the previous check was not correct?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144569

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

[PATCH] D144569: [Clang][OpenMP] Fix accessing of aligned arrays in offloaded target regions

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:2274
+  if (!IsByRef) {
+if ((Ctx.getTargetInfo().getTriple().isAMDGCN()) ||
+(Ctx.getTargetInfo().getTriple().isNVPTX())) {

doru1004 wrote:
> jhuber6 wrote:
> > Why does this handling need to be different between CPU and GPU offloading? 
> > Strictly speaking, I'm not sure why we need the alignment type here since 
> > we'd only get improper alignment on primitive types. So I figured that it 
> > should only care about the alignment of the type itself in all cases. Maybe 
> > someone can correct me on that.
> Are you saying that the previous check was not correct?
This is the first I've looked at this code, so I don't know what the intention 
was. But I would assume it's just making sure that the alignment of the 
`uintptr_t` is sufficient to contain the by-value copy without causing an 
addressing error. By that logic I figured it would only care about the 
alignment of the type, not the declaration itself.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144569

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

[PATCH] D144569: [Clang][OpenMP] Fix accessing of aligned arrays in offloaded target regions

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

doru1004 added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:2274
+  if (!IsByRef) {
+if ((Ctx.getTargetInfo().getTriple().isAMDGCN()) ||
+(Ctx.getTargetInfo().getTriple().isNVPTX())) {

jhuber6 wrote:
> doru1004 wrote:
> > jhuber6 wrote:
> > > Why does this handling need to be different between CPU and GPU 
> > > offloading? Strictly speaking, I'm not sure why we need the alignment 
> > > type here since we'd only get improper alignment on primitive types. So I 
> > > figured that it should only care about the alignment of the type itself 
> > > in all cases. Maybe someone can correct me on that.
> > Are you saying that the previous check was not correct?
> This is the first I've looked at this code, so I don't know what the 
> intention was. But I would assume it's just making sure that the alignment of 
> the `uintptr_t` is sufficient to contain the by-value copy without causing an 
> addressing error. By that logic I figured it would only care about the 
> alignment of the type, not the declaration itself.
Assuming that what was there before was correct, then you're saying that the 
Decl type is always the same as Ty. Is that the case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144569

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

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

[Qiongsi Wu via Phabricator via cfe-commits]

qiongsiwu1 updated this revision to Diff 500298.
qiongsiwu1 added a comment.

> This accepts -mno-roptr for other platforms despite having no semantic 
> functionality (e.g., it does not move variables to a different section for 
> ELF codegen).

Thanks for catching this @hubert.reinterpretcast !! The patch is updated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144190

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/AIX.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/PowerPC/aix-roptr.c
  clang/test/Driver/ppc-roptr.c

Index: clang/test/Driver/ppc-roptr.c
===
--- /dev/null
+++ clang/test/Driver/ppc-roptr.c
@@ -0,0 +1,18 @@
+// RUN: %clang -### -target powerpc-ibm-aix-xcoff -mroptr %s 2>&1 | FileCheck %s
+// RUN: %clang -### -target powerpc-ibm-aix-xcoff -mroptr -mno-roptr %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=ROPTR
+// RUN: %clang -### -target powerpc64-ibm-aix-xcoff -mroptr %s 2>&1 | FileCheck %s
+// RUN: %clang -### -target powerpc64-ibm-aix-xcoff -mroptr -mno-roptr %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=ROPTR
+// CHECK: "-mroptr"
+// CHECK: "-bforceimprw"
+// ROPTR-NOT: "-mroptr"
+// ROPTR-NOT: "-bforceimprw"
+
+char c1 = 10;
+char c2 = 20;
+char* const c1_ptr = &c1;
+
+int main() {
+*(char**)&c1_ptr = &c2;
+}
Index: clang/test/CodeGen/PowerPC/aix-roptr.c
===
--- /dev/null
+++ clang/test/CodeGen/PowerPC/aix-roptr.c
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -triple=powerpc-ibm-aix-xcoff -mroptr -fdata-sections \
+// RUN: -S <%s | FileCheck %s --check-prefix=CHECK32
+// RUN: %clang_cc1 -triple=powerpc64-ibm-aix-xcoff -mroptr -fdata-sections \
+// RUN: -S <%s | FileCheck %s --check-prefix=CHECK64
+// RUN: not %clang_cc1 -triple=powerpc-ibm-aix-xcoff -mroptr \
+// RUN: -S <%s 2>&1 | FileCheck %s --check-prefix=DATA_SECTION_ERR
+// RUN: not %clang_cc1 -triple=powerpc64-ibm-aix-xcoff -mroptr \
+// RUN: -S <%s 2>&1 | FileCheck %s --check-prefix=DATA_SECTION_ERR
+// RUN: not %clang_cc1 -triple=powerpc64le-unknown-linux-gnu -mroptr \
+// RUN: -S <%s 2>&1 | FileCheck %s --check-prefix=TARGET_ROPTR_ERR
+// RUN: not %clang -Xclang -triple=powerpc64le-unknown-linux-gnu -mno-roptr \
+// RUN: -S %s 2>&1 | FileCheck %s --check-prefix=TARGET_NOROPTR_ERR
+// RUN: not %clang -Xclang -triple=powerpc-ibm-aix-xcoff -mroptr -shared \
+// RUN: -S %s 2>&1 | FileCheck %s --check-prefix=SHARED_ERR
+// RUN: not %clang -Xclang -triple=powerpc64-ibm-aix-xcoff -mroptr -shared \
+// RUN: -S %s 2>&1 | FileCheck %s --check-prefix=SHARED_ERR
+
+char c1 = 10;
+char c2 = 20;
+char* const c1_ptr = &c1;
+// CHECK32: .csect c1_ptr[RO],2
+// CHECK32-NEXT:	.globl	c1_ptr[RO]
+// CHECK32-NEXT:	.align	2
+// CHECK32-NEXT:	.vbyte	4, c1[RW]
+
+// CHECK64: .csect c1_ptr[RO],3
+// CHECK64-NEXT:	.globl	c1_ptr[RO]
+// CHECK64-NEXT:	.align	3
+// CHECK64-NEXT:	.vbyte	8, c1[RW]
+
+// DATA_SECTION_ERR: error: -mroptr is supported only with -fdata-sections
+// TARGET_ROPTR_ERR: error: unsupported option '-mroptr' for target 'powerpc64le-unknown-linux-gnu'
+// TARGET_NOROPTR_ERR: error: unsupported option '-mno-roptr' for target 'powerpc64le-unknown-linux-gnu'
+// SHARED_ERR: error: -mroptr is not suppored with -shared
+
+int main() {
+*(char**)&c1_ptr = &c2;
+}
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1560,6 +1560,9 @@
   if (Opts.EnableAIXExtendedAltivecABI)
 GenerateArg(Args, OPT_mabi_EQ_vec_extabi, SA);
 
+  if (Opts.ReadOnlyPointers)
+GenerateArg(Args, OPT_mroptr, SA);
+
   if (!Opts.OptRecordPasses.empty())
 GenerateArg(Args, OPT_opt_record_passes, Opts.OptRecordPasses, SA);
 
@@ -1949,6 +1952,17 @@
 Opts.EnableAIXExtendedAltivecABI = O.matches(OPT_mabi_EQ_vec_extabi);
   }
 
+  if (Arg *A = Args.getLastArg(OPT_mroptr)) {
+if (!T.isOSAIX())
+  Diags.Report(diag::err_drv_unsupported_opt_for_target)
+  << A->getSpelling() << T.str();
+
+if (!Args.hasFlag(OPT_fdata_sections, OPT_fno_data_sections, false))
+  Diags.Report(diag::err_roptr_requires_data_sections);
+
+Opts.ReadOnlyPointers = true;
+  }
+
   if (Arg *A = Args.getLastArg(OPT_mabi_EQ_quadword_atomics)) {
 if (!T.isOSAIX() || T.isPPC32())
   Diags.Report(diag::err_drv_unsupported_opt_for_target)
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clan

[PATCH] D144569: [Clang][OpenMP] Fix accessing of aligned arrays in offloaded target regions

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:2274
+  if (!IsByRef) {
+if ((Ctx.getTargetInfo().getTriple().isAMDGCN()) ||
+(Ctx.getTargetInfo().getTriple().isNVPTX())) {

doru1004 wrote:
> jhuber6 wrote:
> > doru1004 wrote:
> > > jhuber6 wrote:
> > > > Why does this handling need to be different between CPU and GPU 
> > > > offloading? Strictly speaking, I'm not sure why we need the alignment 
> > > > type here since we'd only get improper alignment on primitive types. So 
> > > > I figured that it should only care about the alignment of the type 
> > > > itself in all cases. Maybe someone can correct me on that.
> > > Are you saying that the previous check was not correct?
> > This is the first I've looked at this code, so I don't know what the 
> > intention was. But I would assume it's just making sure that the alignment 
> > of the `uintptr_t` is sufficient to contain the by-value copy without 
> > causing an addressing error. By that logic I figured it would only care 
> > about the alignment of the type, not the declaration itself.
> Assuming that what was there before was correct, then you're saying that the 
> Decl type is always the same as Ty. Is that the case?
I figured that we'd only care about the alignment of the type that's being 
copied. Because it's not like we can mimic the alignment of the variable on the 
device. We just need to make sure that its alignment is `<= 
alignof(uintptr_t)`. Maybe I'm wrong there, someone else could chime in.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144569

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

[PATCH] D140925: [CMake] Use Clang to infer the target triple

[Shoaib Meenai via Phabricator via cfe-commits]

smeenai added a comment.

Ping @ldionne, would you be able to take a look at this soon (or are you okay 
waiving the libc++ blocking requirement for it)? This is really useful for 
Android armv7, where the triple is traditionally spelled 
armv7-none-linux-androideabi but normalized to arvm7-none-linux-android, and 
this patch would resolve that discrepancy.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140925

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

[PATCH] D135495: [clang-tidy] handle exceptions properly in `ExceptionAnalyzer`

[Domján Dániel via Phabricator via cfe-commits]

isuckatcs updated this revision to Diff 500299.
isuckatcs added a comment.

Fixed the timed out test


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

https://reviews.llvm.org/D135495

Files:
  clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.cpp
  clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.h
  clang-tools-extra/test/clang-tidy/checkers/bugprone/exception-escape.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone/exception-escape.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone/exception-escape.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone/exception-escape.cpp
@@ -101,6 +101,126 @@
   }
 }
 
+void throw_catch_pointer_c() noexcept {
+  try {
+int a = 1;
+throw &a;
+  } catch(const int *) {}
+}
+
+void throw_catch_pointer_v() noexcept {
+  try {
+int a = 1;
+throw &a;
+  } catch(volatile int *) {}
+}
+
+void throw_catch_pointer_cv() noexcept {
+  try {
+int a = 1;
+throw &a;
+  } catch(const volatile int *) {}
+}
+
+void throw_catch_multi_ptr_1() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_catch_multi_ptr_1' which should not throw exceptions
+  try {
+char **p = 0;
+throw p;
+  } catch (const char **) {
+  }
+}
+
+void throw_catch_multi_ptr_2() noexcept {
+  try {
+char **p = 0;
+throw p;
+  } catch (const char *const *) {
+  }
+}
+
+void throw_catch_multi_ptr_3() noexcept {
+  try {
+char **p = 0;
+throw p;
+  } catch (volatile char *const *) {
+  }
+}
+
+void throw_catch_multi_ptr_4() noexcept {
+  try {
+char **p = 0;
+throw p;
+  } catch (volatile const char *const *) {
+  }
+}
+
+// FIXME: In this case 'a' is convertible to the handler and should be caught
+// but in reality it's thrown. Note that clang doesn't report a warning for 
+// this either.
+void throw_catch_multi_ptr_5() noexcept {
+  try {
+double *a[2][3];
+throw a;
+  } catch (double *(*)[3]) {
+  }
+}
+
+
+void throw_c_catch_pointer() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_c_catch_pointer' which should not throw exceptions
+  try {
+int a = 1;
+const int *p = &a;
+throw p;
+  } catch(int *) {}
+}
+
+void throw_c_catch_pointer_v() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_c_catch_pointer_v' which should not throw exceptions
+  try {
+int a = 1;
+const int *p = &a;
+throw p;
+  } catch(volatile int *) {}
+}
+
+void throw_v_catch_pointer() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_v_catch_pointer' which should not throw exceptions
+  try {
+int a = 1;
+volatile int *p = &a;
+throw p;
+  } catch(int *) {}
+}
+
+void throw_v_catch_pointer_c() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_v_catch_pointer_c' which should not throw exceptions
+  try {
+int a = 1;
+volatile int *p = &a;
+throw p;
+  } catch(const int *) {}
+}
+
+void throw_cv_catch_pointer_c() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_cv_catch_pointer_c' which should not throw exceptions
+  try {
+int a = 1;
+const volatile int *p = &a;
+throw p;
+  } catch(const int *) {}
+}
+
+void throw_cv_catch_pointer_v() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_cv_catch_pointer_v' which should not throw exceptions
+  try {
+int a = 1;
+const volatile int *p = &a;
+throw p;
+  } catch(volatile int *) {}
+}
+
 class base {};
 class derived: public base {};
 
@@ -112,6 +232,265 @@
   }
 }
 
+void throw_derived_alias_catch_base() noexcept {
+  using alias = derived;
+
+  try {
+throw alias();
+  } catch(base &) {
+  }
+}
+
+void throw_derived_catch_base_alias() noexcept {
+  using alias = base;
+
+  try {
+throw derived();
+  } catch(alias &) {
+  }
+}
+
+void throw_derived_catch_base_ptr_c() noexcept {
+  try {
+derived d;
+throw &d; 
+  } catch(const base *) {
+  }
+}
+
+void throw_derived_catch_base_ptr() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_derived_catch_base_ptr' which should not throw exceptions
+  try {
+derived d;
+const derived *p = &d;
+throw p; 
+  } catch(base *) {
+  }
+}
+
+class A {};
+class B : A {};
+
+// The following alias hell is deliberately created for testing.
+using aliasedA = A;
+class C : protected aliasedA {};
+
+typedef aliasedA moreAliasedA;
+class D : public moreAliasedA {};
+
+using moreMoreAliasedA = moreAliasedA;
+using aliasedD = D;
+class E : public moreMoreAliasedA, public aliasedD {};
+
+void throw_derived_catch_base_private() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6:

[PATCH] D135495: [clang-tidy] handle exceptions properly in `ExceptionAnalyzer`

[Domján Dániel via Phabricator via cfe-commits]

isuckatcs added a comment.

> As long as you don't need the library (which, if you have a preprocessed file 
> or a test, should absolutely not be necessary), you can just do the -cc1 
> option of -triple , or the non- -cc1 option of -target .
>
> Both use basically the same options list, and that bot seems to be 
> "aarch64-unknown-linux-gnu" (see under cmake-stage-1 the llvm host triple)

Thanks for this hint, it helped a lot!


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

https://reviews.llvm.org/D135495

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

[PATCH] D140925: [CMake] Use Clang to infer the target triple

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D140925#4151524 , @smeenai wrote:

> Ping @ldionne, would you be able to take a look at this soon (or are you okay 
> waiving the libc++ blocking requirement for it)? This is really useful for 
> Android armv7, where the triple is traditionally spelled 
> armv7-none-linux-androideabi but normalized to arvm7-none-linux-android, and 
> this patch would resolve that discrepancy.

This patch looks reasonable. The target triple example can be added into "and 
avoids the issue where the build uses a different triple spelling." @phosek


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140925

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

[PATCH] D144709: [clang-format] Improve west to east const

[Alexander Hederstaf via Phabricator via cfe-commits]

AlexanderHederstaf added a comment.

> Highlight by me. That is not acceptable, running the output of `clang-format` 
> through `clang-format` shall not result in any change. In that case it's 
> better to not touch it in any way.

That is no longer an issue in the latest patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144709

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

[PATCH] D140996: [c++20] P1907R1: Support for generalized non-type template arguments of scalar type.

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/test/CXX/temp/temp.arg/temp.arg.nontype/p1.cpp:204
+#if __cplusplus == 201703L
+  // cxx17-error@-3 {{non-type template argument refers to subobject '(int 
*)1'}}
+#endif

Shouldn't this be an error b/c it is a temporary? What is `(int*)1` a subobject 
of?



Comment at: clang/test/SemaTemplate/temp_arg_nontype_cxx20.cpp:21
+using IPn = IntPtr<&n + 1>;
+using IPn = IntPtr<&n + 1>;
 

`using IPn = IntPtr<&n + 2>` should be an error since that would be out of 
bounds, while `+1` is ok b/c it is one past the end as long as we don't deref.



Comment at: clang/test/SemaTemplate/temp_arg_nontype_cxx20.cpp:21
+using IPn = IntPtr<&n + 1>;
+using IPn = IntPtr<&n + 1>;
 

shafik wrote:
> `using IPn = IntPtr<&n + 2>` should be an error since that would be out of 
> bounds, while `+1` is ok b/c it is one past the end as long as we don't deref.
gcc reject this one but I think their pointer math is wonky here: 
https://godbolt.org/z/fhMqPPefG



Comment at: clang/test/SemaTemplate/temp_arg_nontype_cxx20.cpp:26
 
-using IP3 = IntPtr<&s.n[3]>; // FIXME expected-error {{refers to subobject}}
-using IP3 = IntPtr; // FIXME expected-error {{refers to subobject}}
+using IP3 = IntPtr<&s.n[3]>;
+using IP3 = IntPtr;

We should reject `IntPtr<&s.n[5]>;` again b/c it is out of bounds. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140996

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

[PATCH] D140996: [c++20] P1907R1: Support for generalized non-type template arguments of scalar type.

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/test/CodeGenCXX/template-arguments.cpp:4
+
+template CONSTEXPR T id(T v) { return v; }
+template auto value = id(V);

I don't see any tests covering unions or enums.



Comment at: clang/test/SemaTemplate/temp_arg_nontype_cxx20.cpp:12
+using F1 = Float<1.0f>;
+using F1 = Float<2.0f / 2>;
 

I believe this is IFNDR the template-heads are functionally equivelent but not 
equivelent: https://eel.is/c++draft/temp.class#general-3



Comment at: clang/test/SemaTemplate/temp_arg_nontype_cxx20.cpp:56
+using CF = ComplexFloat<1.0f + 3.0fi>;
+using CF = ComplexFloat<3.0fi + 1.0f>;
 

Can we add an enum example e.g.:

```
enum E{ E1, E2};
template  struct SE {};
using IPE = SE;
using IPE = SE;

```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140996

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

[PATCH] D140996: [c++20] P1907R1: Support for generalized non-type template arguments of scalar type.

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/include/clang/AST/TemplateBase.h:88
+/// so cannot be dependent.
+UncommonValue,
+

erichkeane wrote:
> I definitely hate the name here... Just `Value` makes a bit more sense, but 
> isn't perfectly accurate.  Perhaps `NonTypeValue`?  But that is a little 
> redundant.  `Uncommon` here is just strange and not particularly descriptive. 
This catch all `UncommonValue` feels artificial. Maybe we need a separate out 
the cases into more granular cases like `Float` etc



Comment at: clang/lib/AST/TemplateBase.cpp:204-211
+  if (Type->isIntegralOrEnumerationType() && V.isInt())
+*this = TemplateArgument(Ctx, V.getInt(), Type);
+  else if ((V.isLValue() && V.isNullPointer()) ||
+   (V.isMemberPointer() && !V.getMemberPointerDecl()))
+*this = TemplateArgument(Type, /*isNullPtr=*/true);
+  else if (const ValueDecl *VD = getAsSimpleValueDeclRef(Ctx, Type, V))
+// FIXME: The Declaration form should expose a const ValueDecl*.

erichkeane wrote:
> aaron.ballman wrote:
> > Well this is certainly a unique approach...  Personally, I think it'd be 
> > nice to not assign to `this` within a constructor by calling other 
> > constructor; that falls squarely into "wait, what, can you even DO that?" 
> > kind of questions for me.
> I agree, this function needs to be refactored to call some sort of 'init' 
> function or something, even if we have to refactor the other constructors.  
> This assignment to `*this` is just too strange to let stay.
I am going to third this sentiment, this is definitely not the right approach 
and the fact that you have this ad-hoc case below here also speaks to this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140996

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

[PATCH] D53953: [clang-tidy] Get ClangTidyContext out of the business of storing diagnostics. NFC

[Gaven Rank via Phabricator via cfe-commits]

galapoz1996 added a comment.
Herald added a subscriber: mgehre.
Herald added a project: All.

Indeed, I recognize that completely. I had a small business nearby as well, and 
within a year, several of my neighbors started doing the same. Hence, our town 
has grown considerably. Nevertheless, since this was my first business, I ran 
into problems with https://wow24-7.io/  . They were a huge 
assistance to me! Even several of my neighbors received my recommendation


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D53953

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

[PATCH] D116182: [ASan] Moved optimized callbacks into a separate library.

[Kirill Stoimenov via Phabricator via cfe-commits]

kstoimenov added inline comments.



Comment at: compiler-rt/lib/asan/CMakeLists.txt:198
+ARCHS ${ASAN_SUPPORTED_ARCH}
+OBJECT_LIBS RTAsan_static
+CFLAGS ${ASAN_CFLAGS}

thetruestblue wrote:
> Can you explain the motivation here?
> 
> RTAsan_static object library isn't built on Apple & Apple ASAN doesn't 
> support static libraries. is there a reason why this was added to Apple that 
> I'm missing?
> 
> I don't believe this actually builds anything on Apple platforms since no OS 
> is passed and in add_compiler_rt_runtime no libnames get set.
> 
> Even the tests added are not-apple specific.
As far as I remember it was because of the __asan_report_(load|store)n 
functions defined in asan_rtl_static.cpp. They are defined as weak so that we 
could link the binary without providing the implementation, which was later 
loaded from asan_rtl DSO. 

It is possible that we don't need this on Apple, but we will most likely need 
that on Windows. So if you are planning to make changes here you might have to 
revisit the 'NOT WIN32 AND NOT APPLE' statements to make sure we don't break 
the Windows build. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116182

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

[clang] 8709bca - clang: Add __builtin_elementwise_fma

[Matt Arsenault via cfe-commits]

Author: Matt Arsenault
Date: 2023-02-24T21:55:08-04:00
New Revision: 8709bcacfb3a06847b47bb6b47e8556db43f3a43

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

LOG: clang: Add  __builtin_elementwise_fma

I didn't understand why the other builtins have promotion logic,
or how it would apply for a ternary operation. Implicit conversions
are evil to begin with,  and even more so when the purpose is to get
an exact IR intrinsic. This checks all the arguments have the same type.

Added: 


Modified: 
clang/docs/LanguageExtensions.rst
clang/include/clang/Basic/Builtins.def
clang/include/clang/Sema/Sema.h
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/Sema/SemaChecking.cpp
clang/test/CodeGen/builtins-elementwise-math.c
clang/test/Sema/builtins-elementwise-math.c

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 2595b5de8f265..c0ea8afad6cb2 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -631,6 +631,7 @@ Unless specified otherwise operation(±0) = ±0 and 
operation(±infinity) = ±in
 === 
 
=
  T __builtin_elementwise_abs(T x)return the absolute value of a 
number x; the absolute value of   signed integer and floating point types
  the most negative integer remains 
the most negative integer
+ T __builtin_elementwise_fma(T x, T y, T z)  fused multiply add, (x * y) +  z. 
 floating point types
  T __builtin_elementwise_ceil(T x)   return the smallest integral 
value greater than or equal to xfloating point types
  T __builtin_elementwise_sin(T x)return the sine of x interpreted 
as an angle in radians  floating point types
  T __builtin_elementwise_cos(T x)return the cosine of x 
interpreted as an angle in radiansfloating point types

diff  --git a/clang/include/clang/Basic/Builtins.def 
b/clang/include/clang/Basic/Builtins.def
index 41288410786b0..6db599a3de116 100644
--- a/clang/include/clang/Basic/Builtins.def
+++ b/clang/include/clang/Basic/Builtins.def
@@ -671,6 +671,7 @@ BUILTIN(__builtin_elementwise_sin, "v.", "nct")
 BUILTIN(__builtin_elementwise_trunc, "v.", "nct")
 BUILTIN(__builtin_elementwise_canonicalize, "v.", "nct")
 BUILTIN(__builtin_elementwise_copysign, "v.", "nct")
+BUILTIN(__builtin_elementwise_fma, "v.", "nct")
 BUILTIN(__builtin_elementwise_add_sat, "v.", "nct")
 BUILTIN(__builtin_elementwise_sub_sat, "v.", "nct")
 BUILTIN(__builtin_reduce_max, "v.", "nct")

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 41691eab4972b..0c6a3887e4151 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -13531,6 +13531,7 @@ class Sema final {
   bool CheckPPCMMAType(QualType Type, SourceLocation TypeLoc);
 
   bool SemaBuiltinElementwiseMath(CallExpr *TheCall);
+  bool SemaBuiltinElementwiseTernaryMath(CallExpr *TheCall);
   bool PrepareBuiltinElementwiseMathOneArgCall(CallExpr *TheCall);
   bool PrepareBuiltinReduceMathOneArgCall(CallExpr *TheCall);
 

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 52ec6e092c449..1535b14c7fb40 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -3118,6 +3118,8 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl 
GD, unsigned BuiltinID,
 emitUnaryBuiltin(*this, E, llvm::Intrinsic::canonicalize, 
"elt.trunc"));
   case Builtin::BI__builtin_elementwise_copysign:
 return RValue::get(emitBinaryBuiltin(*this, E, llvm::Intrinsic::copysign));
+  case Builtin::BI__builtin_elementwise_fma:
+return RValue::get(emitTernaryBuiltin(*this, E, llvm::Intrinsic::fma));
   case Builtin::BI__builtin_elementwise_add_sat:
   case Builtin::BI__builtin_elementwise_sub_sat: {
 Value *Op0 = EmitScalarExpr(E->getArg(0));

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index eded6061c77eb..485351f157fde 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -2626,20 +2626,16 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl, 
unsigned BuiltinID,
   return ExprError();
 
 QualType ArgTy = TheCall->getArg(0)->getType();
-QualType EltTy = ArgTy;
-
-if (auto *VecTy = EltTy->getAs())
-  EltTy = VecTy->getElementType();
-if (!EltTy->isFloatingType()) {
-  Diag(TheCall->getArg(0)->getBeginLoc(),
-   diag::err_builtin_invalid_arg_type)
-  << 1 << /* float ty*/ 5 << ArgTy;
-
+if (checkFPMathBuiltinE

[PATCH] D140992: clang: Add __builtin_elementwise_fma

[Matt Arsenault via Phabricator via cfe-commits]

arsenm closed this revision.
arsenm added a comment.

8709bcacfb3a06847b47bb6b47e8556db43f3a43 



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

https://reviews.llvm.org/D140992

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

[PATCH] D114025: [clang][NFC] Inclusive terms: replace some uses of sanity in clang

[Gaven Rank via Phabricator via cfe-commits]

galapoz1996 added a comment.
Herald added subscribers: steakhal, MaskRay.
Herald added a reviewer: NoQ.
Herald added a project: All.

I used to think that therapy was only for people with "real" problems, but I 
couldn't have been more wrong. Seeking help for my anxiety and depression has 
been one of the best decisions I've ever made us.calmerry.com 
 . If you're struggling, don't hesitate to reach out 
for help - there are plenty of resources online to help you find a therapist 
that's right for you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114025

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

[PATCH] D144772: [Sema] Use isSVESizelessBuiltinType instead of isSizelessBuiltinType to prevent crashing on RISC-V.

[Craig Topper via Phabricator via cfe-commits]

craig.topper created this revision.
craig.topper added reviewers: reames, asb, kito-cheng, eopXD, c-rhodes, 
frasercrmck, rogfer01.
Herald added subscribers: luke, VincentWu, ctetreau, vkmr, luismarques, apazos, 
sameer.abuasal, s.egerton, Jim, jocewei, PkmX, the_o, brucehoult, 
MartinMosbeck, edward-jones, zzheng, jrtc27, shiva0217, niosHD, sabuasal, 
simoncook, johnrusso, rbar, tschuett, arichardson.
Herald added a project: All.
craig.topper requested review of this revision.
Herald added a subscriber: pcwang-thead.
Herald added a project: clang.

These 2 spots are protecting calls to SVE specific functions. If RISC-V
sizeless types end up in there we trigger assertions.

Use the more specific isSVESizelessBuiltinType() to avoid letting
RISC-V vectors through.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144772

Files:
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/Sema/attr-riscv-rvv-vector-bits.c


Index: clang/test/Sema/attr-riscv-rvv-vector-bits.c
===
--- clang/test/Sema/attr-riscv-rvv-vector-bits.c
+++ clang/test/Sema/attr-riscv-rvv-vector-bits.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple riscv64-none-linux-gnu -target-feature +zve64x 
-ffreestanding -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple riscv64-none-linux-gnu -target-feature +f 
-target-feature +d -target-feature +zve64d -ffreestanding -fsyntax-only -verify 
%s
 
 // TODO: Support for a arm_sve_vector_bits like attribute will come in the 
future.
 
@@ -60,3 +60,21 @@
 
   gs8 = gs8 & ss8; // expected-error {{invalid operands to binary expression 
('gnu_int8_t' (vector of 8 'int8_t' values) and 'vint8m1_t' (aka 
'__rvv_int8m1_t'))}}
 }
+
+// --//
+// Implicit casts
+
+gnu_int8_t to_gnu_int8_t_from_vint8m1_t_(vint8m1_t x) { return x; } // 
expected-error {{returning 'vint8m1_t' (aka '__rvv_int8m1_t') from a function 
with incompatible result type 'gnu_int8_t' (vector of 8 'int8_t' values)}}
+vint8m1_t from_gnu_int8_t_to_vint8m1_t(gnu_int8_t x) { return x; } // 
expected-error {{returning 'gnu_int8_t' (vector of 8 'int8_t' values) from a 
function with incompatible result type 'vint8m1_t' (aka '__rvv_int8m1_t')}}
+
+// --//
+// Test passing GNU vector scalable function
+
+vint32m1_t __attribute__((overloadable)) vfunc(vint32m1_t op1, vint32m1_t op2);
+vfloat64m1_t __attribute__((overloadable)) vfunc(vfloat64m1_t op1, 
vfloat64m1_t op2);
+
+gnu_int32_t call_int32_ff(gnu_int32_t op1, gnu_int32_t op2) {
+  return vfunc(op1, op2); // expected-error {{no matching function for call to 
'vfunc'}}
+  // expected-note@-5 {{candidate function not viable: 
no known conversion from 'gnu_int32_t' (vector of 2 'int32_t' values) to 
'vint32m1_t' (aka '__rvv_int32m1_t') for 1st argument}}
+  // expected-note@-5 {{candidate function not viable: 
no known conversion from 'gnu_int32_t' (vector of 2 'int32_t' values) to 
'vfloat64m1_t' (aka '__rvv_float64m1_t') for 1st argument}}
+}
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -1750,7 +1750,8 @@
 }
   }
 
-  if (ToType->isSizelessBuiltinType() || FromType->isSizelessBuiltinType())
+  if (ToType->isSVESizelessBuiltinType() ||
+  FromType->isSVESizelessBuiltinType())
 if (S.Context.areCompatibleSveTypes(FromType, ToType) ||
 S.Context.areLaxCompatibleSveTypes(FromType, ToType)) {
   ICK = ICK_SVE_Vector_Conversion;
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -9871,8 +9871,8 @@
 }
 
 // Allow assignments between fixed-length and sizeless SVE vectors.
-if ((LHSType->isSizelessBuiltinType() && RHSType->isVectorType()) ||
-(LHSType->isVectorType() && RHSType->isSizelessBuiltinType()))
+if ((LHSType->isSVESizelessBuiltinType() && RHSType->isVectorType()) ||
+(LHSType->isVectorType() && RHSType->isSVESizelessBuiltinType()))
   if (Context.areCompatibleSveTypes(LHSType, RHSType) ||
   Context.areLaxCompatibleSveTypes(LHSType, RHSType)) {
 Kind = CK_BitCast;
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -9529,9 +9529,10 @@
 
 bool ASTContext::areCompatibleSveTypes(QualType FirstType,
QualType SecondType) {
-  assert(((FirstType->isSizelessBuiltinType() && SecondType->isVectorType()) ||
-  (FirstType->isVectorType() && SecondType->isSizelessBuiltinType())) 
&&
- "Expected

[PATCH] D144778: [Driver][FreeBSD] Further simplify the Driver handling for older FreeBSD releases

[Brad Smith via Phabricator via cfe-commits]

brad created this revision.
brad added reviewers: dim, emaste.
brad added a project: clang.
Herald added subscribers: krytarowski, arichardson.
Herald added a project: All.
brad requested review of this revision.
Herald added a subscriber: MaskRay.

With the last diff as I was simplifying some bits and removing FreeBSD 8 / 9 
support I forgot to do this part as well.

Since GCC 4.2 was removed with 10.0 and newer the respective Driver bits can be 
removed.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144778

Files:
  clang/lib/Driver/ToolChains/FreeBSD.cpp
  clang/lib/Driver/ToolChains/FreeBSD.h


Index: clang/lib/Driver/ToolChains/FreeBSD.h
===
--- clang/lib/Driver/ToolChains/FreeBSD.h
+++ clang/lib/Driver/ToolChains/FreeBSD.h
@@ -71,9 +71,6 @@
 
   void addLibCxxIncludePaths(const llvm::opt::ArgList &DriverArgs,
  llvm::opt::ArgStringList &CC1Args) const override;
-  void
-  addLibStdCxxIncludePaths(const llvm::opt::ArgList &DriverArgs,
-   llvm::opt::ArgStringList &CC1Args) const override;
   void AddCXXStdlibLibArgs(const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) const override;
   void AddCudaIncludeArgs(const llvm::opt::ArgList &DriverArgs,
Index: clang/lib/Driver/ToolChains/FreeBSD.cpp
===
--- clang/lib/Driver/ToolChains/FreeBSD.cpp
+++ clang/lib/Driver/ToolChains/FreeBSD.cpp
@@ -441,30 +441,14 @@
concat(getDriver().SysRoot, "/usr/include/c++/v1"));
 }
 
-void FreeBSD::addLibStdCxxIncludePaths(
-const llvm::opt::ArgList &DriverArgs,
-llvm::opt::ArgStringList &CC1Args) const {
-  addLibStdCXXIncludePaths(concat(getDriver().SysRoot, "/usr/include/c++/4.2"),
-   "", "", DriverArgs, CC1Args);
-}
-
 void FreeBSD::AddCXXStdlibLibArgs(const ArgList &Args,
   ArgStringList &CmdArgs) const {
-  CXXStdlibType Type = GetCXXStdlibType(Args);
   unsigned Major = getTriple().getOSMajorVersion();
   bool Profiling = Args.hasArg(options::OPT_pg) && Major != 0 && Major < 14;
 
-  switch (Type) {
-  case ToolChain::CST_Libcxx:
-CmdArgs.push_back(Profiling ? "-lc++_p" : "-lc++");
-if (Args.hasArg(options::OPT_fexperimental_library))
-  CmdArgs.push_back("-lc++experimental");
-break;
-
-  case ToolChain::CST_Libstdcxx:
-CmdArgs.push_back(Profiling ? "-lstdc++_p" : "-lstdc++");
-break;
-  }
+  CmdArgs.push_back(Profiling ? "-lc++_p" : "-lc++");
+  if (Args.hasArg(options::OPT_fexperimental_library))
+CmdArgs.push_back("-lc++experimental");
 }
 
 void FreeBSD::AddCudaIncludeArgs(const ArgList &DriverArgs,


Index: clang/lib/Driver/ToolChains/FreeBSD.h
===
--- clang/lib/Driver/ToolChains/FreeBSD.h
+++ clang/lib/Driver/ToolChains/FreeBSD.h
@@ -71,9 +71,6 @@
 
   void addLibCxxIncludePaths(const llvm::opt::ArgList &DriverArgs,
  llvm::opt::ArgStringList &CC1Args) const override;
-  void
-  addLibStdCxxIncludePaths(const llvm::opt::ArgList &DriverArgs,
-   llvm::opt::ArgStringList &CC1Args) const override;
   void AddCXXStdlibLibArgs(const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) const override;
   void AddCudaIncludeArgs(const llvm::opt::ArgList &DriverArgs,
Index: clang/lib/Driver/ToolChains/FreeBSD.cpp
===
--- clang/lib/Driver/ToolChains/FreeBSD.cpp
+++ clang/lib/Driver/ToolChains/FreeBSD.cpp
@@ -441,30 +441,14 @@
concat(getDriver().SysRoot, "/usr/include/c++/v1"));
 }
 
-void FreeBSD::addLibStdCxxIncludePaths(
-const llvm::opt::ArgList &DriverArgs,
-llvm::opt::ArgStringList &CC1Args) const {
-  addLibStdCXXIncludePaths(concat(getDriver().SysRoot, "/usr/include/c++/4.2"),
-   "", "", DriverArgs, CC1Args);
-}
-
 void FreeBSD::AddCXXStdlibLibArgs(const ArgList &Args,
   ArgStringList &CmdArgs) const {
-  CXXStdlibType Type = GetCXXStdlibType(Args);
   unsigned Major = getTriple().getOSMajorVersion();
   bool Profiling = Args.hasArg(options::OPT_pg) && Major != 0 && Major < 14;
 
-  switch (Type) {
-  case ToolChain::CST_Libcxx:
-CmdArgs.push_back(Profiling ? "-lc++_p" : "-lc++");
-if (Args.hasArg(options::OPT_fexperimental_library))
-  CmdArgs.push_back("-lc++experimental");
-break;
-
-  case ToolChain::CST_Libstdcxx:
-CmdArgs.push_back(Profiling ? "-lstdc++_p" : "-lstdc++");
-break;
-  }
+  CmdArgs.push_back(Profiling ? "-lc++_p" : "-lc++");
+  if (Args.hasArg(options::OPT_fexperimental_library))
+CmdArgs.push_back("-lc++experimental");
 }
 
 void FreeBSD::AddCudaIncludeArgs(const ArgList &DriverArgs,
__

[PATCH] D144703: [clangd] Avoid using CompletionItemKind.Text for macro completions

[Nathan Ridge via Phabricator via cfe-commits]

nridge updated this revision to Diff 500087.
nridge added a comment.

use Constant rather than Variable for object-like macros


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144703

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -627,7 +627,7 @@
 has("variable", CompletionItemKind::Variable),
 has("int", CompletionItemKind::Keyword),
 has("Struct", CompletionItemKind::Struct),
-has("MACRO", CompletionItemKind::Text),
+has("MACRO", CompletionItemKind::Constant),
 has("indexFunction", CompletionItemKind::Function),
 has("indexVariable", CompletionItemKind::Variable),
 has("indexClass", CompletionItemKind::Class)));
@@ -3789,7 +3789,7 @@
  kind(CompletionItemKind::Constructor;
   EXPECT_THAT(completions(Context + "MAC^(2)", {}, Opts).Completions,
   Contains(AllOf(labeled("MACRO(x)"), snippetSuffix(""),
- kind(CompletionItemKind::Text;
+ kind(CompletionItemKind::Function;
 }
 
 TEST(CompletionTest, NoCrashDueToMacroOrdering) {
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -150,22 +150,24 @@
   llvm_unreachable("Unhandled clang::index::SymbolKind.");
 }
 
-CompletionItemKind
-toCompletionItemKind(CodeCompletionResult::ResultKind ResKind,
- const NamedDecl *Decl,
- CodeCompletionContext::Kind CtxKind) {
-  if (Decl)
-return toCompletionItemKind(index::getSymbolInfo(Decl).Kind);
+CompletionItemKind toCompletionItemKind(const CodeCompletionResult &Res,
+CodeCompletionContext::Kind CtxKind) {
+  if (Res.Declaration)
+return toCompletionItemKind(index::getSymbolInfo(Res.Declaration).Kind);
   if (CtxKind == CodeCompletionContext::CCC_IncludedFile)
 return CompletionItemKind::File;
-  switch (ResKind) {
+  switch (Res.Kind) {
   case CodeCompletionResult::RK_Declaration:
 llvm_unreachable("RK_Declaration without Decl");
   case CodeCompletionResult::RK_Keyword:
 return CompletionItemKind::Keyword;
   case CodeCompletionResult::RK_Macro:
-return CompletionItemKind::Text; // unfortunately, there's no 'Macro'
- // completion items in LSP.
+// There is no 'Macro' kind in LSP.
+// Avoid using 'Text' to avoid confusion with client-side word-based
+// completion proposals.
+return Res.MacroDefInfo && Res.MacroDefInfo->isFunctionLike()
+   ? CompletionItemKind::Function
+   : CompletionItemKind::Constant;
   case CodeCompletionResult::RK_Pattern:
 return CompletionItemKind::Snippet;
   }
@@ -337,8 +339,7 @@
   Completion.Scope = std::string(
   splitQualifiedName(printQualifiedName(*ND)).first);
   }
-  Completion.Kind = toCompletionItemKind(
-  C.SemaResult->Kind, C.SemaResult->Declaration, ContextKind);
+  Completion.Kind = toCompletionItemKind(*C.SemaResult, ContextKind);
   // Sema could provide more info on whether the completion was a file or
   // folder.
   if (Completion.Kind == CompletionItemKind::File &&


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -627,7 +627,7 @@
 has("variable", CompletionItemKind::Variable),
 has("int", CompletionItemKind::Keyword),
 has("Struct", CompletionItemKind::Struct),
-has("MACRO", CompletionItemKind::Text),
+has("MACRO", CompletionItemKind::Constant),
 has("indexFunction", CompletionItemKind::Function),
 has("indexVariable", CompletionItemKind::Variable),
 has("indexClass", CompletionItemKind::Class)));
@@ -3789,7 +3789,7 @@
  kind(CompletionItemKind::Constructor;
   EXPECT_THAT(completions(Context + "MAC^(2)", {}, Opts).Completions,
   Contains(AllOf(labeled("MACRO(x)"), snippetSuffix(""),
- kind(CompletionItemKind::Text;
+ kind(CompletionItemKind::Function;
 

[PATCH] D144696: [RISCV][NFC] Package version number information using RISCVExtensionVersion.

[yanming via Phabricator via cfe-commits]

ym1813382441 added a comment.

In D144696#4149516 , @craig.topper 
wrote:

> Can you outline your full plan and why you want to do this. We need to see 
> the bigger picture.



In D144696#4149545 , @ym1813382441 
wrote:

> F26630797: Screenshot from 2023-02-24 15-54-21.png 
> 

I'm implementing this idea


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144696

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

[PATCH] D144696: [RISCV][NFC] Package version number information using RISCVExtensionVersion.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

In D144696#4149545 , @ym1813382441 
wrote:

> F26630797: Screenshot from 2023-02-24 15-54-21.png 
> 

I meant what extensions are you planning to support multiple versions for and 
why? How will this work in the assembler, code generator, and disassembler 
which use SubtargetFeatures not RISCVISAInfo.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144696

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

[PATCH] D143096: [clangd] Provide patched diagnostics with preamble patch

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hello,

I noticed that if I compile the compiler with ubsan, then lots of Clangd tests 
start failing with this patch:

  Failed Tests (165):
Clangd :: ast-no-range.test
Clangd :: ast.test
Clangd :: call-hierarchy.test
Clangd :: check-lines.test
Clangd :: check.test
Clangd :: code-action-request.test
Clangd :: completion-auto-trigger.test
Clangd :: completion-snippets.test
Clangd :: completion.test
Clangd :: config.test
Clangd :: crash-parse.test
Clangd :: dependency-output.test
Clangd :: diagnostic-category.test
Clangd :: diagnostics-no-tidy.test
Clangd :: diagnostics-notes.test
Clangd :: diagnostics-tidy.test
Clangd :: did-change-configuration-params.test
Clangd :: execute-command.test
Clangd :: filestatus.test
Clangd :: fixits-codeaction.test
Clangd :: fixits-command.test
Clangd :: fixits-embed-in-diagnostic.test
Clangd :: folding-range.test
Clangd :: formatting.test
Clangd :: hover.test
Clangd :: implementations.test
Clangd :: inlayHints.test
Clangd :: memory_tree.test
Clangd :: metrics.test
Clangd :: protocol.test
Clangd :: references-container.test
Clangd :: references.test
Clangd :: rename.test
Clangd :: request-reply.test
Clangd :: selection-range.test
Clangd :: semantic-tokens-refresh.test
Clangd :: semantic-tokens.test
Clangd :: signature-help-with-offsets.test
Clangd :: signature-help.test
Clangd :: symbol-info.test
Clangd :: symbols.test
Clangd :: target_info.test
Clangd :: test-uri-posix.test
Clangd :: textdocument-didchange-fail.test
Clangd :: trace.test
Clangd :: tweaks-format.test
Clangd :: type-definition.test
Clangd :: type-hierarchy-ext.test
Clangd :: type-hierarchy.test
Clangd :: unsupported-method.test
Clangd :: utf8.test
Clangd :: version.test
Clangd :: xrefs.test
Clangd Unit Tests :: ./ClangdTests/0/146
[...]
Clangd Unit Tests :: ./ClangdTests/99/146
  
  
  Testing Time: 362.21s
Skipped  :47
Unsupported  :  1094
Passed   : 89208
Expectedly Failed:   192
Failed   :   165

Not sure if all fail the same way but there are a lot of ubsan complaints like 
this

  07:38:09 ../lib/Support/MemoryBuffer.cpp:138:33: runtime error: null pointer 
passed as argument 2, which is declared to never be null
  07:38:09 /usr/include/string.h:43:28: note: nonnull attribute specified here
  07:38:09 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
../lib/Support/MemoryBuffer.cpp:138:33 in 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143096

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

[PATCH] D144646: [Tooling][Inclusions] Add c-header and global namespace alternatives for size_t

[Haojian Wu via Phabricator via cfe-commits]

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

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144646

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

[PATCH] D144696: [RISCV][NFC] Package version number information using RISCVExtensionVersion.

[yanming via Phabricator via cfe-commits]

ym1813382441 added a comment.

In D144696#4149560 , @craig.topper 
wrote:

> In D144696#4149545 , @ym1813382441 
> wrote:
>
>> F26630797: Screenshot from 2023-02-24 15-54-21.png 
>> 
>
> I meant what extensions are you planning to support multiple versions for and 
> why? How will this work in the assembler, code generator, and disassembler 
> which use SubtargetFeatures not RISCVISAInfo.

My intention is to support RVV0.71, since specific cpu's exist for the XuanTie 
C900 series. In LLVM use Feature to distinguish between different versions of 
extensions. I am considering how to solve this problem, using multiple `.td` 
files in the worst case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144696

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

[PATCH] D144273: [clang][ASTImporter] Add VaList declaration to lookup table.

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

balazske added a comment.

Probably we can add a new function `ASTContext::getVaListTagDeclIfExists` that 
does not create declarations if these do not exist. These new mentioned test 
cases would probably fail, but with a new non-modifying get function it can 
work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144273

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

[PATCH] D144696: [RISCV][NFC] Package version number information using RISCVExtensionVersion.

[Wang Pengcheng via Phabricator via cfe-commits]

pcwang-thead added a comment.

> My intention is to support RVV0.71, since specific cpu's exist for the 
> XuanTie C900 series. In LLVM use Feature to distinguish between different 
> versions of extensions. I am considering how to solve this problem, using 
> multiple `.td` files in the worst case.

@ym1813382441
Thanks for your works and we really appreciate it. :-)
Similar proposal has been rejected by the community (please refer to D115921 
 for previous discussion) and I don't know if 
others have changed their minds.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144696

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

[PATCH] D144707: [C++20] [Modules] Deprecate to load C++20 Named Modules eagerly

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu created this revision.
ChuanqiXu added reviewers: iains, dblaikie, Bigcheese.
ChuanqiXu added a project: clang-modules.
Herald added a subscriber: jvesely.
Herald added a project: All.
ChuanqiXu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Close https://github.com/llvm/llvm-project/issues/60824

The form -fmodule-file= will load modules eagerly and the form 
-fmodule-file== will load modules lazily. The 
inconsistency adds many additional burdens to the implementations. And the 
inconsistency looks not helpful and necessary neither. So I want to deprecate 
the form -fmodule-file= for named modules. This is pretty helpful 
for us (the developers).

Does this change make any regression from the perspective of the users?

To be honest, yes. But I think such regression is acceptable. Here is the 
example:

  // M.cppm
  export module M;
  export int m = 5;
  
  // N.cpp
  // import M; // woops, we forgot to import M.
  int n = m;

In the original version, the compiler can diagnose the users to import `M` 
since the compiler have already imported M. But in the later style, the 
compiler can only say "unknown identifier `m`".

But I think such regression doesn't make a deal since it only works if the user 
put `-fmodule-file=M.pcm` in the command line. But how can the user put 
`-fmodule-file=M.pcm` in the command line without `import M;`? Especially 
currently such options are generated by build systems. And the build systems 
will only generate the command line from the source file.

So I think this change is pretty pretty helpful for developers and almost 
innocent for users and we should accept this one.

I'll add the release notes and edit the document after we land this.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144707

Files:
  clang/include/clang/Basic/DiagnosticSerializationKinds.td
  clang/lib/Serialization/ASTReader.cpp
  clang/test/CXX/basic/basic.link/p10-ex2.cpp
  clang/test/CXX/basic/basic.link/p2.cpp
  clang/test/CXX/basic/basic.lookup/basic.lookup.argdep/p5-ex2.cpp
  clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
  clang/test/CXX/module/basic/basic.def.odr/p6.cppm
  clang/test/CXX/module/basic/basic.link/module-declaration.cpp
  clang/test/CXX/module/basic/basic.link/p2.cppm
  clang/test/CXX/module/basic/basic.search/module-import.cppm
  clang/test/CXX/module/dcl.dcl/dcl.module/dcl.module.import/p1.cppm
  clang/test/CXX/module/dcl.dcl/dcl.module/dcl.module.interface/p1.cppm
  clang/test/CXX/module/dcl.dcl/dcl.module/p1.cpp
  clang/test/CXX/module/dcl.dcl/dcl.module/p5.cpp
  clang/test/CXX/module/module.context/p7.cpp
  clang/test/CXX/module/module.interface/p1.cpp
  clang/test/CXX/module/module.interface/p2.cpp
  clang/test/CXX/module/module.unit/p8.cpp
  clang/test/Modules/cxx20-10-1-ex2.cpp
  clang/test/Modules/cxx20-10-2-ex2.cpp
  clang/test/Modules/cxx20-10-2-ex5.cpp
  clang/test/Modules/cxx20-10-3-ex1.cpp
  clang/test/Modules/cxx20-10-3-ex2.cpp
  clang/test/Modules/cxx20-10-5-ex1.cpp
  clang/test/Modules/cxx20-import-diagnostics-a.cpp
  clang/test/Modules/cxx20-import-diagnostics-b.cpp
  clang/test/Modules/eagerly-load-cxx-named-modules.cppm
  clang/test/Modules/named-modules-adl-2.cppm
  clang/test/Modules/named-modules-adl.cppm
  clang/test/Modules/pr60036.cppm
  clang/test/SemaCXX/modules.cppm

Index: clang/test/SemaCXX/modules.cppm
===
--- clang/test/SemaCXX/modules.cppm
+++ clang/test/SemaCXX/modules.cppm
@@ -1,32 +1,17 @@
 // RUN: %clang_cc1 -std=c++20 -emit-module-interface %s -o %t.0.pcm -verify -DTEST=0
 // RUN: %clang_cc1 -std=c++20 -emit-module-interface %s -o %t.1.pcm -verify -DTEST=1
-// RUN: %clang_cc1 -std=c++20 -emit-module-interface %s -fmodule-file=%t.0.pcm -o %t.2.pcm -verify -DTEST=2
-// RUN: %clang_cc1 -std=c++20 -emit-module-interface %s -fmodule-file=%t.0.pcm -o %t.3.pcm -verify -Dfoo=bar -DTEST=3
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %s -fmodule-file=foo=%t.0.pcm -o %t.2.pcm -verify -DTEST=2
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %s -fmodule-file=foo=%t.0.pcm -o %t.3.pcm -verify -Dfoo=bar -DTEST=3
 
-#if TEST == 0
+#if TEST == 0 || TEST == 2
 // expected-no-diagnostics
 #endif
 
 export module foo;
-#if TEST == 2
-// expected-error@-2 {{redefinition of module 'foo'}}
-// expected-n...@modules.cppm:* {{loaded from}}
-#endif
 
 static int m;
-#if TEST == 2
-// expected-error@-2 {{redefinition of '}}
-// expected-note@-3 {{unguarded header; consider using #ifdef guards or #pragma once}}
-// FIXME: We should drop the "header from" in this diagnostic.
-// expected-note...@modules.cppm:1 {{'{{.*}}modules.cppm' included multiple times, additional include site in header from module 'foo'}}
-#endif
+
 int n;
-#if TEST == 2
-// expected-error@-2 {{redefinition of '}}
-// expected-note@-3 {{unguarded header; consider using #ifdef guards or #pragma onc

[PATCH] D144708: [clangd] Fix UB in scanPreamble

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

getMemBufferCopy triggers an UB when it receives a default constructed
StringRef. Make sure that we're always passing the null-terminated string
created in ParseInputs throughout the scanPreamble.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144708

Files:
  clang-tools-extra/clangd/Preamble.cpp


Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -332,6 +332,8 @@
   EmptyFS FS;
   // Build and run Preprocessor over the preamble.
   ParseInputs PI;
+  // Memory buffers below expect null-terminated && non-null strings. So make
+  // sure to always use PI.Contents!
   PI.Contents = Contents.str();
   PI.TFS = &FS;
   PI.CompileCommand = Cmd;
@@ -346,7 +348,7 @@
   // elsewhere.
   auto Bounds = ComputePreambleBounds(*CI->getLangOpts(), *ContentsBuffer, 0);
   auto PreambleContents =
-  llvm::MemoryBuffer::getMemBufferCopy(Contents.substr(0, Bounds.Size));
+  llvm::MemoryBuffer::getMemBufferCopy(PI.Contents.substr(0, Bounds.Size));
   auto Clang = prepareCompilerInstance(
   std::move(CI), nullptr, std::move(PreambleContents),
   // Provide an empty FS to prevent preprocessor from performing IO. This
@@ -371,7 +373,7 @@
 return std::move(Err);
   Action.EndSourceFile();
   SP.Includes = std::move(Includes.MainFileIncludes);
-  llvm::append_range(SP.Lines, llvm::split(Contents, "\n"));
+  llvm::append_range(SP.Lines, llvm::split(PI.Contents, "\n"));
   return SP;
 }
 
@@ -739,9 +741,8 @@
   //   whole preamble, which is terribly slow.
   // - If scanning for Modified fails, cannot figure out newly added ones so
   //   there's nothing to do but generate an empty patch.
-  auto BaselineScan = scanPreamble(
-  // Contents needs to be null-terminated.
-  Baseline.Preamble.getContents(), Modified.CompileCommand);
+  auto BaselineScan =
+  scanPreamble(Baseline.Preamble.getContents(), Modified.CompileCommand);
   if (!BaselineScan) {
 elog("Failed to scan baseline of {0}: {1}", FileName,
  BaselineScan.takeError());


Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -332,6 +332,8 @@
   EmptyFS FS;
   // Build and run Preprocessor over the preamble.
   ParseInputs PI;
+  // Memory buffers below expect null-terminated && non-null strings. So make
+  // sure to always use PI.Contents!
   PI.Contents = Contents.str();
   PI.TFS = &FS;
   PI.CompileCommand = Cmd;
@@ -346,7 +348,7 @@
   // elsewhere.
   auto Bounds = ComputePreambleBounds(*CI->getLangOpts(), *ContentsBuffer, 0);
   auto PreambleContents =
-  llvm::MemoryBuffer::getMemBufferCopy(Contents.substr(0, Bounds.Size));
+  llvm::MemoryBuffer::getMemBufferCopy(PI.Contents.substr(0, Bounds.Size));
   auto Clang = prepareCompilerInstance(
   std::move(CI), nullptr, std::move(PreambleContents),
   // Provide an empty FS to prevent preprocessor from performing IO. This
@@ -371,7 +373,7 @@
 return std::move(Err);
   Action.EndSourceFile();
   SP.Includes = std::move(Includes.MainFileIncludes);
-  llvm::append_range(SP.Lines, llvm::split(Contents, "\n"));
+  llvm::append_range(SP.Lines, llvm::split(PI.Contents, "\n"));
   return SP;
 }
 
@@ -739,9 +741,8 @@
   //   whole preamble, which is terribly slow.
   // - If scanning for Modified fails, cannot figure out newly added ones so
   //   there's nothing to do but generate an empty patch.
-  auto BaselineScan = scanPreamble(
-  // Contents needs to be null-terminated.
-  Baseline.Preamble.getContents(), Modified.CompileCommand);
+  auto BaselineScan =
+  scanPreamble(Baseline.Preamble.getContents(), Modified.CompileCommand);
   if (!BaselineScan) {
 elog("Failed to scan baseline of {0}: {1}", FileName,
  BaselineScan.takeError());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D142890: [clangd] Add config option for fast diagnostics mode

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

In D142890#4149181 , @vitalybuka 
wrote:

> One of your patches likely introduced UB 
> https://lab.llvm.org/buildbot/#/builders/85/builds/14558
> Can you please take a look?

Thanks a lot Vitaly and sorry for not noticing this myself :(
This sounds to me like a bad consequence between an empty stringref and 
memorybuffers. I've put together https://reviews.llvm.org/D144706 to make sure 
we can prevent this from happening in the library, but getting it reviewed will 
probably take time.
In the meanwhile I've sent out https://reviews.llvm.org/D144708 to stop the 
bleeding.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142890

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

[PATCH] D143096: [clangd] Provide patched diagnostics with preamble patch

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

thanks for the ping! see the discussion in 
https://reviews.llvm.org/D142890#4149679


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143096

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

[PATCH] D144707: [C++20] [Modules] Deprecate to load C++20 Named Modules eagerly

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

For example, the issue (https://github.com/llvm/llvm-project/issues/60085) 
disappears after we change the eagerly loading to lazily loading.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144707

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

[PATCH] D144696: [RISCV][NFC] Package version number information using RISCVExtensionVersion.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

How much of the existing vector code in the backend including tablegen can be 
reused for 0.71? How much of the intrinsic interface can be used? If we’re 
talking about completely duplicating everything it is very unlikely we can 
accept it. RISCVGenDAGISel.inc, for example, is already significantly larger 
than any other target in tree. I don’t know how big it can get before it 
becomes an issue.

How many people are going to maintain this other version?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144696

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

[PATCH] D144708: [clangd] Fix UB in scanPreamble

[Haojian Wu via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/Preamble.cpp:351
   auto PreambleContents =
-  llvm::MemoryBuffer::getMemBufferCopy(Contents.substr(0, Bounds.Size));
+  llvm::MemoryBuffer::getMemBufferCopy(PI.Contents.substr(0, Bounds.Size));
   auto Clang = prepareCompilerInstance(

Looks like we have an extra cost here -- the std::string.substr will construct 
a new string everytime, we could save it by using 
`llvm::StringRef(PI.Contents).substr(0, Bounds.Size)`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144708

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

[PATCH] D144709: [clang-format] Improve west to east const

[Alexander Hederstaf via Phabricator via cfe-commits]

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

  Qualifiers were not moved for non-pointer non-simple types.
  Remove the requirement for *,&,&& and add extra checks for
  previous tokens. Further simplify the logic for types by
  additional requirements on tokens preceeding the current
  test.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144709

Files:
  clang/lib/Format/QualifierAlignmentFixer.cpp

Index: clang/lib/Format/QualifierAlignmentFixer.cpp
===
--- clang/lib/Format/QualifierAlignmentFixer.cpp
+++ clang/lib/Format/QualifierAlignmentFixer.cpp
@@ -217,62 +217,61 @@
   if (LeftRightQualifierAlignmentFixer::isPossibleMacro(Tok->Next))
 return Tok;
 
-  auto AnalyzeTemplate =
-  [&](const FormatToken *Tok,
-  const FormatToken *StartTemplate) -> const FormatToken * {
-// Read from the TemplateOpener to TemplateCloser.
-FormatToken *EndTemplate = StartTemplate->MatchingParen;
-if (EndTemplate) {
-  // Move to the end of any template class members e.g.
-  // `Foo::iterator`.
-  if (EndTemplate->startsSequence(TT_TemplateCloser, tok::coloncolon,
-  tok::identifier)) {
-EndTemplate = EndTemplate->Next->Next;
-  }
-}
-if (EndTemplate && EndTemplate->Next &&
-!EndTemplate->Next->isOneOf(tok::equal, tok::l_paren)) {
-  insertQualifierAfter(SourceMgr, Fixes, EndTemplate, Qualifier);
-  // Remove the qualifier.
-  removeToken(SourceMgr, Fixes, Tok);
-  return Tok;
+  const FormatToken *PreviousCheck = Tok->Previous;
+  while (PreviousCheck && llvm::is_contained(ConfiguredQualifierTokens,
+ PreviousCheck->Tok.getKind())) {
+PreviousCheck = PreviousCheck->Previous;
+  }
+
+  const bool IsEastQualifier = PreviousCheck && [PreviousCheck]() {
+if (PreviousCheck->is(tok::r_paren)) {
+  return true;
+} else if (PreviousCheck->is(TT_TemplateCloser)) {
+  return PreviousCheck->MatchingParen->Previous->isNot(tok::kw_template);
+} else if (PreviousCheck->isOneOf(TT_PointerOrReference, tok::identifier,
+  tok::kw_auto)) {
+  return true;
 }
-return nullptr;
-  };
+return false;
+  }();
 
-  FormatToken *Qual = Tok->Next;
-  FormatToken *LastQual = Qual;
-  while (Qual && isQualifierOrType(Qual, ConfiguredQualifierTokens)) {
-LastQual = Qual;
-Qual = Qual->Next;
+  const FormatToken *LastQual = Tok;
+  while (LastQual->Next && llvm::is_contained(ConfiguredQualifierTokens,
+  LastQual->Next->Tok.getKind())) {
+LastQual = LastQual->Next;
+  }
+
+  if (IsEastQualifier) {
+if (LastQual != Tok)
+  rotateTokens(SourceMgr, Fixes, Tok, LastQual, /*Left=*/false);
+return Tok;
   }
-  if (LastQual && Qual != LastQual) {
-rotateTokens(SourceMgr, Fixes, Tok, LastQual, /*Left=*/false);
-Tok = LastQual;
-  } else if (Tok->startsSequence(QualifierType, tok::identifier,
- TT_TemplateCloser)) {
-FormatToken *Closer = Tok->Next->Next;
-rotateTokens(SourceMgr, Fixes, Tok, Tok->Next, /*Left=*/false);
-Tok = Closer;
+
+  const FormatToken *TypeToken = LastQual->Next;
+  if (!TypeToken)
 return Tok;
-  } else if (Tok->startsSequence(QualifierType, tok::identifier,
- TT_TemplateOpener)) {
-// `const ArrayRef a;`
-// `const ArrayRef &a;`
-const FormatToken *NewTok = AnalyzeTemplate(Tok, Tok->Next->Next);
-if (NewTok)
-  return NewTok;
-  } else if (Tok->startsSequence(QualifierType, tok::coloncolon,
- tok::identifier, TT_TemplateOpener)) {
-// `const ::ArrayRef a;`
-// `const ::ArrayRef &a;`
-const FormatToken *NewTok = AnalyzeTemplate(Tok, Tok->Next->Next->Next);
-if (NewTok)
-  return NewTok;
-  } else if (Tok->startsSequence(QualifierType, tok::identifier) ||
- Tok->startsSequence(QualifierType, tok::coloncolon,
- tok::identifier)) {
-FormatToken *Next = Tok->Next;
+
+  if (TypeToken->isSimpleTypeSpecifier()) {
+const FormatToken *LastSimpleTypeSpecifier = TypeToken;
+while (LastSimpleTypeSpecifier->Next &&
+   LastSimpleTypeSpecifier->Next->isSimpleTypeSpecifier()) {
+  LastSimpleTypeSpecifier = LastSimpleTypeSpecifier->Next;
+}
+rotateTokens(SourceMgr, Fixes, Tok, LastSimpleTypeSpecifier,
+ /*Left=*/false);
+return LastSimpleTypeSpecifier;
+  } else if (PreviousCheck && PreviousCheck->isSimpleTypeSpecifier()) {
+if (LastQual != Tok)
+  rotateTokens(SourceMgr, Fixes, Tok, LastQual, /*Left=*/false);
+return Tok;
+  }
+
+  if (TypeToken->is(tok::co

[PATCH] D144703: [clangd] Avoid using CompletionItemKind.Text for macro completions

[Haojian Wu via Phabricator via cfe-commits]

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

Thanks, this looks an improvement to me!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144703

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

[PATCH] D143560: clang-format.el: fix warnings

[Philipp via Phabricator via cfe-commits]

phst added a comment.

I'm not super familiar with the process either, but IIRC @sammccall or @djasper 
have to merge this.


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

https://reviews.llvm.org/D143560

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

[PATCH] D144709: [clang-format] Improve west to east const

[Alexander Hederstaf via Phabricator via cfe-commits]

AlexanderHederstaf added a reviewer: MyDeveloperDay.
AlexanderHederstaf added a comment.

I tried to refactor QualifierAlignmentFixer to handle more types, notably 
removing the *,&,&& requirement as e.g. const Foo did not work. To avoid moving 
qualifiers too far, a test for "already east const" is introduced. However, to 
get the correct order for the east qualifiers Clang-Format must be used twice. 
I assume it's related to how fixes/replacements are handled. Would you like to 
have a look and perhaps suggest any improvements?

As it must be used twice, some tests related to volatile/const order fail, but 
I noticed most of them would also fails previously if the type is not simple.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144709

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

[PATCH] D144696: [RISCV][NFC] Package version number information using RISCVExtensionVersion.

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

@ym1813382441 thanks for the contribution. In many cases, this kind of 
incremental and tightly focused patch is a good way to start things. But in 
this case, there's a few bigger issues.

- As has been pointed out, the discussion about supporting multiple ISA 
versions has been started before. The barrier isn't the code change required, 
but more about agreeing we actually want/need to support multiple extension 
versions simultaneously (RISC-V International seem to have indicated they'd add 
new named extensions rather than add instructions to an existing extension in 
the future), and perhaps the biggest blocker has been around the handling of 
build attributes, what is accepted / produces an error / produces a warning by 
what tool and so on. We've been discussing this in the recent RISC-V LLVM 
sync-up calls and a few people who've been thinking about these issues for a 
while are hoping to come up with a proposal in the coming weeks.
- If the ultimate intention is to support V0.7, then as Craig suggests that's a 
much bigger discussion. We really need to understand what the level of changes 
would be required, how this would impact in-tree code for V1.0, what the burden 
might be going forwards and so on. Not all points are relevant, but I've often 
thought that the considerations for Contributing Extensions to Clang 
 provide a good starting point. e.g.
  - Evidence of a significant user community
  - A specific need to reside within the upstream tree
  - A long term support plan
  - A high quality implementation
  - Testing


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144696

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

[PATCH] D144708: [clangd] Fix UB in scanPreamble

[Kadir Cetinkaya via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/Preamble.cpp:351
   auto PreambleContents =
-  llvm::MemoryBuffer::getMemBufferCopy(Contents.substr(0, Bounds.Size));
+  llvm::MemoryBuffer::getMemBufferCopy(PI.Contents.substr(0, Bounds.Size));
   auto Clang = prepareCompilerInstance(

hokein wrote:
> Looks like we have an extra cost here -- the std::string.substr will 
> construct a new string everytime, we could save it by using 
> `llvm::StringRef(PI.Contents).substr(0, Bounds.Size)`.
thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144708

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

[PATCH] D144696: [RISCV][NFC] Package version number information using RISCVExtensionVersion.

[yanming via Phabricator via cfe-commits]

ym1813382441 added a comment.

In D144696#4149706 , @craig.topper 
wrote:

> How much of the existing vector code in the backend including tablegen can be 
> reused for 0.71? How much of the intrinsic interface can be used? If we’re 
> talking about completely duplicating everything it is very unlikely we can 
> accept it. RISCVGenDAGISel.inc, for example, is already significantly larger 
> than any other target in tree. I don’t know how big it can get before it 
> becomes an issue.
>
> How many people are going to maintain this other version?

I will not submit RVV0.71 to the community, I just want to extend the interface 
to support multiple versions, this will help to solve the compatibility issue 
of different versions of the extension, this issue is common.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144696

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

[clang-tools-extra] c4972d3 - [clangd] Avoid using CompletionItemKind.Text for macro completions

[Nathan Ridge via cfe-commits]

Author: Nathan Ridge
Date: 2023-02-24T04:41:27-05:00
New Revision: c4972d37290ff5ab1228ecfc7280bc07a9280f92

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

LOG: [clangd] Avoid using CompletionItemKind.Text for macro completions

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

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

Added: 


Modified: 
clang-tools-extra/clangd/CodeComplete.cpp
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/CodeComplete.cpp 
b/clang-tools-extra/clangd/CodeComplete.cpp
index 04494f9cda5b4..98fa285f71051 100644
--- a/clang-tools-extra/clangd/CodeComplete.cpp
+++ b/clang-tools-extra/clangd/CodeComplete.cpp
@@ -150,22 +150,24 @@ CompletionItemKind toCompletionItemKind(index::SymbolKind 
Kind) {
   llvm_unreachable("Unhandled clang::index::SymbolKind.");
 }
 
-CompletionItemKind
-toCompletionItemKind(CodeCompletionResult::ResultKind ResKind,
- const NamedDecl *Decl,
- CodeCompletionContext::Kind CtxKind) {
-  if (Decl)
-return toCompletionItemKind(index::getSymbolInfo(Decl).Kind);
+CompletionItemKind toCompletionItemKind(const CodeCompletionResult &Res,
+CodeCompletionContext::Kind CtxKind) {
+  if (Res.Declaration)
+return toCompletionItemKind(index::getSymbolInfo(Res.Declaration).Kind);
   if (CtxKind == CodeCompletionContext::CCC_IncludedFile)
 return CompletionItemKind::File;
-  switch (ResKind) {
+  switch (Res.Kind) {
   case CodeCompletionResult::RK_Declaration:
 llvm_unreachable("RK_Declaration without Decl");
   case CodeCompletionResult::RK_Keyword:
 return CompletionItemKind::Keyword;
   case CodeCompletionResult::RK_Macro:
-return CompletionItemKind::Text; // unfortunately, there's no 'Macro'
- // completion items in LSP.
+// There is no 'Macro' kind in LSP.
+// Avoid using 'Text' to avoid confusion with client-side word-based
+// completion proposals.
+return Res.MacroDefInfo && Res.MacroDefInfo->isFunctionLike()
+   ? CompletionItemKind::Function
+   : CompletionItemKind::Constant;
   case CodeCompletionResult::RK_Pattern:
 return CompletionItemKind::Snippet;
   }
@@ -337,8 +339,7 @@ struct CodeCompletionBuilder {
   Completion.Scope = std::string(
   splitQualifiedName(printQualifiedName(*ND)).first);
   }
-  Completion.Kind = toCompletionItemKind(
-  C.SemaResult->Kind, C.SemaResult->Declaration, ContextKind);
+  Completion.Kind = toCompletionItemKind(*C.SemaResult, ContextKind);
   // Sema could provide more info on whether the completion was a file or
   // folder.
   if (Completion.Kind == CompletionItemKind::File &&

diff  --git a/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp 
b/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
index 56e156dd84b75..f57f266c3c511 100644
--- a/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ b/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -639,7 +639,7 @@ TEST(CompletionTest, Kinds) {
 has("variable", CompletionItemKind::Variable),
 has("int", CompletionItemKind::Keyword),
 has("Struct", CompletionItemKind::Struct),
-has("MACRO", CompletionItemKind::Text),
+has("MACRO", CompletionItemKind::Constant),
 has("indexFunction", CompletionItemKind::Function),
 has("indexVariable", CompletionItemKind::Variable),
 has("indexClass", CompletionItemKind::Class)));
@@ -3801,7 +3801,7 @@ TEST(CompletionTest, FunctionArgsExist) {
  kind(CompletionItemKind::Constructor;
   EXPECT_THAT(completions(Context + "MAC^(2)", {}, Opts).Completions,
   Contains(AllOf(labeled("MACRO(x)"), snippetSuffix(""),
- kind(CompletionItemKind::Text;
+ kind(CompletionItemKind::Function;
 }
 
 TEST(CompletionTest, NoCrashDueToMacroOrdering) {



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

[PATCH] D144703: [clangd] Avoid using CompletionItemKind.Text for macro completions

[Nathan Ridge via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc4972d37290f: [clangd] Avoid using CompletionItemKind.Text 
for macro completions (authored by nridge).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144703

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -639,7 +639,7 @@
 has("variable", CompletionItemKind::Variable),
 has("int", CompletionItemKind::Keyword),
 has("Struct", CompletionItemKind::Struct),
-has("MACRO", CompletionItemKind::Text),
+has("MACRO", CompletionItemKind::Constant),
 has("indexFunction", CompletionItemKind::Function),
 has("indexVariable", CompletionItemKind::Variable),
 has("indexClass", CompletionItemKind::Class)));
@@ -3801,7 +3801,7 @@
  kind(CompletionItemKind::Constructor;
   EXPECT_THAT(completions(Context + "MAC^(2)", {}, Opts).Completions,
   Contains(AllOf(labeled("MACRO(x)"), snippetSuffix(""),
- kind(CompletionItemKind::Text;
+ kind(CompletionItemKind::Function;
 }
 
 TEST(CompletionTest, NoCrashDueToMacroOrdering) {
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -150,22 +150,24 @@
   llvm_unreachable("Unhandled clang::index::SymbolKind.");
 }
 
-CompletionItemKind
-toCompletionItemKind(CodeCompletionResult::ResultKind ResKind,
- const NamedDecl *Decl,
- CodeCompletionContext::Kind CtxKind) {
-  if (Decl)
-return toCompletionItemKind(index::getSymbolInfo(Decl).Kind);
+CompletionItemKind toCompletionItemKind(const CodeCompletionResult &Res,
+CodeCompletionContext::Kind CtxKind) {
+  if (Res.Declaration)
+return toCompletionItemKind(index::getSymbolInfo(Res.Declaration).Kind);
   if (CtxKind == CodeCompletionContext::CCC_IncludedFile)
 return CompletionItemKind::File;
-  switch (ResKind) {
+  switch (Res.Kind) {
   case CodeCompletionResult::RK_Declaration:
 llvm_unreachable("RK_Declaration without Decl");
   case CodeCompletionResult::RK_Keyword:
 return CompletionItemKind::Keyword;
   case CodeCompletionResult::RK_Macro:
-return CompletionItemKind::Text; // unfortunately, there's no 'Macro'
- // completion items in LSP.
+// There is no 'Macro' kind in LSP.
+// Avoid using 'Text' to avoid confusion with client-side word-based
+// completion proposals.
+return Res.MacroDefInfo && Res.MacroDefInfo->isFunctionLike()
+   ? CompletionItemKind::Function
+   : CompletionItemKind::Constant;
   case CodeCompletionResult::RK_Pattern:
 return CompletionItemKind::Snippet;
   }
@@ -337,8 +339,7 @@
   Completion.Scope = std::string(
   splitQualifiedName(printQualifiedName(*ND)).first);
   }
-  Completion.Kind = toCompletionItemKind(
-  C.SemaResult->Kind, C.SemaResult->Declaration, ContextKind);
+  Completion.Kind = toCompletionItemKind(*C.SemaResult, ContextKind);
   // Sema could provide more info on whether the completion was a file or
   // folder.
   if (Completion.Kind == CompletionItemKind::File &&


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -639,7 +639,7 @@
 has("variable", CompletionItemKind::Variable),
 has("int", CompletionItemKind::Keyword),
 has("Struct", CompletionItemKind::Struct),
-has("MACRO", CompletionItemKind::Text),
+has("MACRO", CompletionItemKind::Constant),
 has("indexFunction", CompletionItemKind::Function),
 has("indexVariable", CompletionItemKind::Variable),
 has("indexClass", CompletionItemKind::Class)));
@@ -3801,7 +3801,7 @@
  kind(CompletionItemKind::Constructor;
   EXPECT_THAT(completions(Context + "MAC^(2)", {}, Opts).Completions,
   Contains(AllOf(labeled("MACRO(x)"), snippetSuffix(""),
- kind(CompletionItemKind::Text;
+

[clang-tools-extra] f393e1f - [clangd] Fix UB in scanPreamble

[Kadir Cetinkaya via cfe-commits]

Author: Kadir Cetinkaya
Date: 2023-02-24T10:43:12+01:00
New Revision: f393e1f6b3b42e8f355e64e2fb479c571ab939bc

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

LOG: [clangd] Fix UB in scanPreamble

getMemBufferCopy triggers an UB when it receives a default constructed
StringRef. Make sure that we're always passing the null-terminated string
created in ParseInputs throughout the scanPreamble.

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

Added: 


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

Removed: 




diff  --git a/clang-tools-extra/clangd/Preamble.cpp 
b/clang-tools-extra/clangd/Preamble.cpp
index e97564497954..f50597f9ad20 100644
--- a/clang-tools-extra/clangd/Preamble.cpp
+++ b/clang-tools-extra/clangd/Preamble.cpp
@@ -332,6 +332,8 @@ scanPreamble(llvm::StringRef Contents, const 
tooling::CompileCommand &Cmd) {
   EmptyFS FS;
   // Build and run Preprocessor over the preamble.
   ParseInputs PI;
+  // Memory buffers below expect null-terminated && non-null strings. So make
+  // sure to always use PI.Contents!
   PI.Contents = Contents.str();
   PI.TFS = &FS;
   PI.CompileCommand = Cmd;
@@ -345,8 +347,8 @@ scanPreamble(llvm::StringRef Contents, const 
tooling::CompileCommand &Cmd) {
   // twice. However, it's important to precisely follow the preamble bounds 
used
   // elsewhere.
   auto Bounds = ComputePreambleBounds(*CI->getLangOpts(), *ContentsBuffer, 0);
-  auto PreambleContents =
-  llvm::MemoryBuffer::getMemBufferCopy(Contents.substr(0, Bounds.Size));
+  auto PreambleContents = llvm::MemoryBuffer::getMemBufferCopy(
+  llvm::StringRef(PI.Contents).take_front(Bounds.Size));
   auto Clang = prepareCompilerInstance(
   std::move(CI), nullptr, std::move(PreambleContents),
   // Provide an empty FS to prevent preprocessor from performing IO. This
@@ -739,9 +741,8 @@ PreamblePatch PreamblePatch::create(llvm::StringRef 
FileName,
   //   whole preamble, which is terribly slow.
   // - If scanning for Modified fails, cannot figure out newly added ones so
   //   there's nothing to do but generate an empty patch.
-  auto BaselineScan = scanPreamble(
-  // Contents needs to be null-terminated.
-  Baseline.Preamble.getContents(), Modified.CompileCommand);
+  auto BaselineScan =
+  scanPreamble(Baseline.Preamble.getContents(), Modified.CompileCommand);
   if (!BaselineScan) {
 elog("Failed to scan baseline of {0}: {1}", FileName,
  BaselineScan.takeError());



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

[PATCH] D144708: [clangd] Fix UB in scanPreamble

[Kadir Cetinkaya via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
kadircet marked an inline comment as done.
Closed by commit rGf393e1f6b3b4: [clangd] Fix UB in scanPreamble (authored by 
kadircet).

Changed prior to commit:
  https://reviews.llvm.org/D144708?vs=500101&id=500112#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144708

Files:
  clang-tools-extra/clangd/Preamble.cpp


Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -332,6 +332,8 @@
   EmptyFS FS;
   // Build and run Preprocessor over the preamble.
   ParseInputs PI;
+  // Memory buffers below expect null-terminated && non-null strings. So make
+  // sure to always use PI.Contents!
   PI.Contents = Contents.str();
   PI.TFS = &FS;
   PI.CompileCommand = Cmd;
@@ -345,8 +347,8 @@
   // twice. However, it's important to precisely follow the preamble bounds 
used
   // elsewhere.
   auto Bounds = ComputePreambleBounds(*CI->getLangOpts(), *ContentsBuffer, 0);
-  auto PreambleContents =
-  llvm::MemoryBuffer::getMemBufferCopy(Contents.substr(0, Bounds.Size));
+  auto PreambleContents = llvm::MemoryBuffer::getMemBufferCopy(
+  llvm::StringRef(PI.Contents).take_front(Bounds.Size));
   auto Clang = prepareCompilerInstance(
   std::move(CI), nullptr, std::move(PreambleContents),
   // Provide an empty FS to prevent preprocessor from performing IO. This
@@ -739,9 +741,8 @@
   //   whole preamble, which is terribly slow.
   // - If scanning for Modified fails, cannot figure out newly added ones so
   //   there's nothing to do but generate an empty patch.
-  auto BaselineScan = scanPreamble(
-  // Contents needs to be null-terminated.
-  Baseline.Preamble.getContents(), Modified.CompileCommand);
+  auto BaselineScan =
+  scanPreamble(Baseline.Preamble.getContents(), Modified.CompileCommand);
   if (!BaselineScan) {
 elog("Failed to scan baseline of {0}: {1}", FileName,
  BaselineScan.takeError());


Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -332,6 +332,8 @@
   EmptyFS FS;
   // Build and run Preprocessor over the preamble.
   ParseInputs PI;
+  // Memory buffers below expect null-terminated && non-null strings. So make
+  // sure to always use PI.Contents!
   PI.Contents = Contents.str();
   PI.TFS = &FS;
   PI.CompileCommand = Cmd;
@@ -345,8 +347,8 @@
   // twice. However, it's important to precisely follow the preamble bounds used
   // elsewhere.
   auto Bounds = ComputePreambleBounds(*CI->getLangOpts(), *ContentsBuffer, 0);
-  auto PreambleContents =
-  llvm::MemoryBuffer::getMemBufferCopy(Contents.substr(0, Bounds.Size));
+  auto PreambleContents = llvm::MemoryBuffer::getMemBufferCopy(
+  llvm::StringRef(PI.Contents).take_front(Bounds.Size));
   auto Clang = prepareCompilerInstance(
   std::move(CI), nullptr, std::move(PreambleContents),
   // Provide an empty FS to prevent preprocessor from performing IO. This
@@ -739,9 +741,8 @@
   //   whole preamble, which is terribly slow.
   // - If scanning for Modified fails, cannot figure out newly added ones so
   //   there's nothing to do but generate an empty patch.
-  auto BaselineScan = scanPreamble(
-  // Contents needs to be null-terminated.
-  Baseline.Preamble.getContents(), Modified.CompileCommand);
+  auto BaselineScan =
+  scanPreamble(Baseline.Preamble.getContents(), Modified.CompileCommand);
   if (!BaselineScan) {
 elog("Failed to scan baseline of {0}: {1}", FileName,
  BaselineScan.takeError());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 385c8cd - [Tooling][Inclusions] Add c-header and global namespace alternatives for size_t

[Kadir Cetinkaya via cfe-commits]

Author: Kadir Cetinkaya
Date: 2023-02-24T10:44:33+01:00
New Revision: 385c8cd3cd66052dee2dff01bfdbeb258191f2ff

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

LOG: [Tooling][Inclusions] Add c-header and global namespace alternatives for 
size_t

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

Added: 


Modified: 
clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc

Removed: 




diff  --git a/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc 
b/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
index c9632bee1cbec..119952be6fe3c 100644
--- a/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ b/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -22,6 +22,20 @@ SYMBOL(size_t, std::, )
 SYMBOL(size_t, std::, )
 SYMBOL(size_t, std::, )
 SYMBOL(size_t, std::, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
 SYMBOL(unwrap_ref_decay, std::, )
 SYMBOL(unwrap_ref_decay, std::, )
 SYMBOL(unwrap_reference, std::, )



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

[PATCH] D144696: [RISCV][NFC] Package version number information using RISCVExtensionVersion.

[Wang Pengcheng via Phabricator via cfe-commits]

pcwang-thead added a comment.

In D144696#4149706 , @craig.topper 
wrote:

> How much of the existing vector code in the backend including tablegen can be 
> reused for 0.71? How much of the intrinsic interface can be used? If we’re 
> talking about completely duplicating everything it is very unlikely we can 
> accept it. RISCVGenDAGISel.inc, for example, is already significantly larger 
> than any other target in tree. I don’t know how big it can get before it 
> becomes an issue.
>
> How many people are going to maintain this other version?

Just FYI. We have tried our best to reuse code for RVV 1.0 and there are about 
500 lines for C intrinsics, 80 lines for LLVM intrinsics, 1200 lines for 
pseudos and patterns and 1500 lines for custom ISel. The pseudos/patterns/ISel 
parts can be less since we have duplicated some code and the impact on 
`RISCVGenDAGISel.inc` is hard to estimate because we have some custom 
extensions. And for MC layer, the code are completely duplicated since a lot of 
instructions have different encodings.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144696

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

[PATCH] D144646: [Tooling][Inclusions] Add c-header and global namespace alternatives for size_t

[Kadir Cetinkaya via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG385c8cd3cd66: [Tooling][Inclusions] Add c-header and global 
namespace alternatives for size_t (authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144646

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc


Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -22,6 +22,20 @@
 SYMBOL(size_t, std::, )
 SYMBOL(size_t, std::, )
 SYMBOL(size_t, std::, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
 SYMBOL(unwrap_ref_decay, std::, )
 SYMBOL(unwrap_ref_decay, std::, )
 SYMBOL(unwrap_reference, std::, )


Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -22,6 +22,20 @@
 SYMBOL(size_t, std::, )
 SYMBOL(size_t, std::, )
 SYMBOL(size_t, std::, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
+SYMBOL(size_t, None, )
 SYMBOL(unwrap_ref_decay, std::, )
 SYMBOL(unwrap_ref_decay, std::, )
 SYMBOL(unwrap_reference, std::, )
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] e6e753d - [clang][dataflow] Fix wrong assert for CXXConstructExpr

[Paul Semel via cfe-commits]

Author: Paul Semel
Date: 2023-02-24T09:51:10Z
New Revision: e6e753d173db14bb1273db65387dec696b7d7a48

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

LOG: [clang][dataflow] Fix wrong assert for CXXConstructExpr

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

Added: 


Modified: 
clang/lib/Analysis/FlowSensitive/Transfer.cpp
clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Removed: 




diff  --git a/clang/lib/Analysis/FlowSensitive/Transfer.cpp 
b/clang/lib/Analysis/FlowSensitive/Transfer.cpp
index 74dd59851ad44..389865771c16b 100644
--- a/clang/lib/Analysis/FlowSensitive/Transfer.cpp
+++ b/clang/lib/Analysis/FlowSensitive/Transfer.cpp
@@ -561,7 +561,9 @@ class TransferVisitor : public 
ConstStmtVisitor {
 assert(ConstructorDecl != nullptr);
 
 if (ConstructorDecl->isCopyOrMoveConstructor()) {
-  assert(S->getNumArgs() == 1);
+  // It is permissible for a copy/move constructor to have additional
+  // parameters as long as they have default arguments defined for them.
+  assert(S->getNumArgs() != 0);
 
   const Expr *Arg = S->getArg(0);
   assert(Arg != nullptr);

diff  --git a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
index f626eb0c01548..98021ce0d30b3 100644
--- a/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -2102,6 +2102,54 @@ TEST(TransferTest, CopyConstructor) {
   });
 }
 
+TEST(TransferTest, CopyConstructorWithDefaultArgument) {
+  std::string Code = R"(
+struct A {
+  int Baz;
+  A() = default;
+  A(const A& a, bool def = true) { Baz = a.Baz; }
+};
+
+void target() {
+  A Foo;
+  (void)Foo.Baz;
+  A Bar = Foo;
+  // [[p]]
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results.keys(), UnorderedElementsAre("p"));
+const Environment &Env = getEnvironmentAtAnnotation(Results, "p");
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+
+const ValueDecl *BazDecl = findValueDecl(ASTCtx, "Baz");
+ASSERT_THAT(BazDecl, NotNull());
+
+const auto *FooLoc = cast(
+Env.getStorageLocation(*FooDecl, SkipPast::None));
+const auto *BarLoc = cast(
+Env.getStorageLocation(*BarDecl, SkipPast::None));
+
+const auto *FooVal = cast(Env.getValue(*FooLoc));
+const auto *BarVal = cast(Env.getValue(*BarLoc));
+EXPECT_EQ(FooVal, BarVal);
+
+const auto *FooBazVal =
+cast(Env.getValue(FooLoc->getChild(*BazDecl)));
+const auto *BarBazVal =
+cast(Env.getValue(BarLoc->getChild(*BazDecl)));
+EXPECT_EQ(FooBazVal, BarBazVal);
+  });
+}
+
 TEST(TransferTest, CopyConstructorWithParens) {
   std::string Code = R"(
 struct A {



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

[PATCH] D144546: [clang][dataflow] Fix assert for CXXConstructExpr argument number

[Paul Semel 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 rGe6e753d173db: [clang][dataflow] Fix wrong assert for 
CXXConstructExpr (authored by paulsemel).
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144546

Files:
  clang/lib/Analysis/FlowSensitive/Transfer.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp


Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -2102,6 +2102,54 @@
   });
 }
 
+TEST(TransferTest, CopyConstructorWithDefaultArgument) {
+  std::string Code = R"(
+struct A {
+  int Baz;
+  A() = default;
+  A(const A& a, bool def = true) { Baz = a.Baz; }
+};
+
+void target() {
+  A Foo;
+  (void)Foo.Baz;
+  A Bar = Foo;
+  // [[p]]
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results.keys(), UnorderedElementsAre("p"));
+const Environment &Env = getEnvironmentAtAnnotation(Results, "p");
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+
+const ValueDecl *BazDecl = findValueDecl(ASTCtx, "Baz");
+ASSERT_THAT(BazDecl, NotNull());
+
+const auto *FooLoc = cast(
+Env.getStorageLocation(*FooDecl, SkipPast::None));
+const auto *BarLoc = cast(
+Env.getStorageLocation(*BarDecl, SkipPast::None));
+
+const auto *FooVal = cast(Env.getValue(*FooLoc));
+const auto *BarVal = cast(Env.getValue(*BarLoc));
+EXPECT_EQ(FooVal, BarVal);
+
+const auto *FooBazVal =
+cast(Env.getValue(FooLoc->getChild(*BazDecl)));
+const auto *BarBazVal =
+cast(Env.getValue(BarLoc->getChild(*BazDecl)));
+EXPECT_EQ(FooBazVal, BarBazVal);
+  });
+}
+
 TEST(TransferTest, CopyConstructorWithParens) {
   std::string Code = R"(
 struct A {
Index: clang/lib/Analysis/FlowSensitive/Transfer.cpp
===
--- clang/lib/Analysis/FlowSensitive/Transfer.cpp
+++ clang/lib/Analysis/FlowSensitive/Transfer.cpp
@@ -561,7 +561,9 @@
 assert(ConstructorDecl != nullptr);
 
 if (ConstructorDecl->isCopyOrMoveConstructor()) {
-  assert(S->getNumArgs() == 1);
+  // It is permissible for a copy/move constructor to have additional
+  // parameters as long as they have default arguments defined for them.
+  assert(S->getNumArgs() != 0);
 
   const Expr *Arg = S->getArg(0);
   assert(Arg != nullptr);


Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -2102,6 +2102,54 @@
   });
 }
 
+TEST(TransferTest, CopyConstructorWithDefaultArgument) {
+  std::string Code = R"(
+struct A {
+  int Baz;
+  A() = default;
+  A(const A& a, bool def = true) { Baz = a.Baz; }
+};
+
+void target() {
+  A Foo;
+  (void)Foo.Baz;
+  A Bar = Foo;
+  // [[p]]
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results.keys(), UnorderedElementsAre("p"));
+const Environment &Env = getEnvironmentAtAnnotation(Results, "p");
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+
+const ValueDecl *BazDecl = findValueDecl(ASTCtx, "Baz");
+ASSERT_THAT(BazDecl, NotNull());
+
+const auto *FooLoc = cast(
+Env.getStorageLocation(*FooDecl, SkipPast::None));
+const auto *BarLoc = cast(
+Env.getStorageLocation(*BarDecl, SkipPast::None));
+
+const auto *FooVal = cast(Env.getValue(*FooLoc));
+const auto *BarVal = cast(Env.getValue(*BarLoc));
+EXPECT_EQ(FooVal, BarVal);
+
+const auto *FooBazVal =
+cast(Env.getValue(FooLoc->getChild(*BazDecl)));
+const auto *BarBazVal =
+cast(Env.getValue(BarLoc->getChild(*BazDecl)));
+EXPECT_EQ(FooBazVal, BarBazVal);
+  });
+}
+
 TEST(TransferTest, CopyConstructorWithParens) {
   std::string Code = R"(
 struct A {
Index: clang/lib/Analysis/FlowSensitive/Transfer.cpp
=

[PATCH] D124351: [Clang] Implement Change scope of lambda trailing-return-type

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin updated this revision to Diff 500117.
cor3ntin marked 18 inline comments as done.
cor3ntin added a comment.

Address Shafik's comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124351

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/Sema/Scope.h
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/Scope.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCXXScopeSpec.cpp
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/p11-1y.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/p4.cpp
  clang/test/SemaCXX/lambda-capture-type-deduction.cpp
  clang/test/SemaCXX/lambda-expressions.cpp
  clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1366,7 +1366,7 @@
 
   Change scope of lambda trailing-return-type
   https://wg21.link/P2036R3";>P2036R3
-  No
+  Clang 17
 
 
   https://wg21.link/P2579R0";>P2579R0
Index: clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
===
--- clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
+++ clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
@@ -95,7 +95,7 @@
 #ifdef AVOID
   auto l4 = [var = param] (int param) { ; }; // no warning
 #else
-  auto l4 = [var = param] (int param) { ; }; // expected-warning {{declaration shadows a local variable}}
+  auto l4 = [var = param](int param) { ; }; // expected-warning 2{{declaration shadows a local variable}}
 #endif
 
   // Make sure that inner lambdas work as well.
Index: clang/test/SemaCXX/lambda-expressions.cpp
===
--- clang/test/SemaCXX/lambda-expressions.cpp
+++ clang/test/SemaCXX/lambda-expressions.cpp
@@ -665,3 +665,27 @@
 // expected-note@-2 2 {{default capture by}}
 }
 };
+
+namespace GH60518 {
+// Lambdas should not try to capture
+// function parameters that are used in enable_if
+struct StringLiteral {
+template 
+StringLiteral(const char (&array)[N])
+__attribute__((enable_if(__builtin_strlen(array) == 2,
+  "invalid string literal")));
+};
+
+namespace cpp_attribute {
+struct StringLiteral {
+template 
+StringLiteral(const char (&array)[N]) [[clang::annotate_type("test", array)]];
+};
+}
+
+void Func1() {
+  [[maybe_unused]] auto y = [&](decltype(StringLiteral("xx"))) {};
+  [[maybe_unused]] auto z = [&](decltype(cpp_attribute::StringLiteral("xx"))) {};
+}
+
+}
Index: clang/test/SemaCXX/lambda-capture-type-deduction.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/lambda-capture-type-deduction.cpp
@@ -0,0 +1,243 @@
+// RUN: %clang_cc1 -std=c++2b -verify -fsyntax-only %s
+
+template 
+constexpr bool is_same = false;
+
+template 
+constexpr bool is_same = true;
+
+void f() {
+
+  int y;
+
+  static_assert(is_same decltype((x)) { return x; }())>);
+
+  static_assert(is_same decltype((x)) { return x; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  auto ref = [&x = y](
+ decltype([&](decltype(x)) { return 0; }) y) {
+return x;
+  };
+}
+
+void test_noexcept() {
+
+  int y;
+
+  static_assert(noexcept([x = 1] noexcept(is_same) {}()));
+  static_assert(noexcept([x = 1] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([y] noexcept(is_same) {}()));
+  static_assert(noexcept([y] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([=] noexcept(is_same) {}()));
+  static_assert(noexcept([=] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([&] noexcept(is_same) {}()));
+  static_assert(noexcept([&] mutable noexcept(is_same) {}()));
+}
+
+void test_requires() {
+
+  int x;
+
+  [x = 1]() requires is_same {}
+  ();
+  [x = 1]() mutable requires is_same {}
+  ();
+  [x]() requires is_same {}
+  ();
+  [x]() mutable requires is_same {}
+  ();
+  [=]() requires is_same {}
+  ();
+  [=]() mutable requires is_same {}
+  ();
+  [&]() requires is_same {}
+  ();
+  [&]() mutable requires is_same {}
+  ();
+  [&x]() requires is_same {}
+  ();
+  [&x]() mutable requires is_same {}
+  ();
+
+  [x = 1]() requires is_same {} ();
+  [x = 1]() mutable requires is_same {} ();
+}
+
+void err() {
+  int y, z;
+  (void)[x = 1]
+  requires(is_same) {};
+

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

[Manuel Klimek via Phabricator via cfe-commits]

klimek updated this revision to Diff 500121.
klimek marked 6 inline comments as done.
klimek added a comment.

Address review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144170

Files:
  clang/include/clang/Format/Format.h
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/MacroExpander.cpp
  clang/lib/Format/Macros.h
  clang/lib/Format/TokenAnalyzer.cpp
  clang/lib/Format/TokenAnalyzer.h
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/TokenAnnotator.h
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/lib/Format/UnwrappedLineParser.h
  clang/lib/Format/WhitespaceManager.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/MacroCallReconstructorTest.cpp
  clang/unittests/Format/MacroExpanderTest.cpp
  clang/unittests/Format/TestLexer.h

Index: clang/unittests/Format/TestLexer.h
===
--- clang/unittests/Format/TestLexer.h
+++ clang/unittests/Format/TestLexer.h
@@ -72,7 +72,8 @@
   TokenList annotate(llvm::StringRef Code) {
 FormatTokenLexer Lex = getNewLexer(Code);
 auto Tokens = Lex.lex();
-UnwrappedLineParser Parser(Style, Lex.getKeywords(), 0, Tokens, *this);
+UnwrappedLineParser Parser(SourceMgr.get(), Style, Lex.getKeywords(), 0,
+   Tokens, *this, Allocator, IdentTable);
 Parser.parse();
 TokenAnnotator Annotator(Style, Lex.getKeywords());
 for (auto &Line : UnwrappedLines) {
Index: clang/unittests/Format/MacroExpanderTest.cpp
===
--- clang/unittests/Format/MacroExpanderTest.cpp
+++ clang/unittests/Format/MacroExpanderTest.cpp
@@ -19,9 +19,16 @@
Lex.Allocator, Lex.IdentTable);
   }
 
+  std::string expand(MacroExpander &Macros, llvm::StringRef Name) {
+EXPECT_TRUE(Macros.defined(Name))
+<< "Macro not defined: \"" << Name << "\"";
+return text(Macros.expand(Lex.id(Name), {}));
+  }
+
   std::string expand(MacroExpander &Macros, llvm::StringRef Name,
- const std::vector &Args = {}) {
-EXPECT_TRUE(Macros.defined(Name));
+ const std::vector &Args) {
+EXPECT_TRUE(Macros.defined(Name))
+<< "Macro not defined: \"" << Name << "\"";
 return text(Macros.expand(Lex.id(Name), lexArgs(Args)));
   }
 
@@ -95,7 +102,7 @@
   EXPECT_EQ("", expand(*Macros, "A"));
   EXPECT_EQ("b", expand(*Macros, "B"));
   EXPECT_EQ("c+c", expand(*Macros, "C"));
-  EXPECT_EQ("", expand(*Macros, "D"));
+  EXPECT_EQ("", expand(*Macros, "D", {}));
 }
 
 TEST_F(MacroExpanderTest, ExpandsWithArguments) {
@@ -105,7 +112,6 @@
   });
   EXPECT_EQ("", expand(*Macros, "A", {"a"}));
   EXPECT_EQ("b1+b2+b3", expand(*Macros, "B", {"b1", "b2 + b3"}));
-  EXPECT_EQ("x+", expand(*Macros, "B", {"x"}));
 }
 
 TEST_F(MacroExpanderTest, AttributizesTokens) {
@@ -200,6 +206,14 @@
   EXPECT_ATTRIBUTES(Result, Attributes);
 }
 
+TEST_F(MacroExpanderTest, Overloads) {
+  auto Macros = create({"A=x", "A()=y", "A(a)=a", "A(a, b)=a b"});
+  EXPECT_EQ("x", expand(*Macros, "A"));
+  EXPECT_EQ("y", expand(*Macros, "A", {}));
+  EXPECT_EQ("z", expand(*Macros, "A", {"z"}));
+  EXPECT_EQ("xy", expand(*Macros, "A", {"x", "y"}));
+}
+
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/unittests/Format/MacroCallReconstructorTest.cpp
===
--- clang/unittests/Format/MacroCallReconstructorTest.cpp
+++ clang/unittests/Format/MacroCallReconstructorTest.cpp
@@ -33,13 +33,31 @@
   TokenList
   expand(llvm::StringRef Name,
  const SmallVector, 1> &Args) {
+return expandInternal(Name, Args);
+  }
+
+  TokenList expand(llvm::StringRef Name) { return expandInternal(Name, {}); }
+
+  TokenList expand(llvm::StringRef Name, const std::vector &Args) {
+return expandInternal(Name, lexArgs(Args));
+  }
+
+  const UnexpandedMap &getUnexpanded() const { return Unexpanded; }
+
+  const TokenList &getTokens() const { return Tokens; }
+
+private:
+  TokenList expandInternal(
+  llvm::StringRef Name,
+  const std::optional, 1>>
+  &Args) {
 auto *ID = Lex.id(Name);
 auto UnexpandedLine = std::make_unique();
 UnexpandedLine->Tokens.push_back(ID);
-if (!Args.empty()) {
+if (Args && !Args->empty()) {
   UnexpandedLine->Tokens.push_back(Lex.id("("));
-  for (auto I = Args.begin(), E = Args.end(); I != E; ++I) {
-if (I != Args.begin())
+  for (auto I = Args->begin(), E = Args->end(); I != E; ++I) {
+if (I != Args->begin())
   UnexpandedLine->Tokens.push_back(Lex.id(","));
 UnexpandedLine->Tokens.insert(UnexpandedLine->Tokens.end(), I->begin(),
  

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

[Manuel Klimek via Phabricator via cfe-commits]

klimek added inline comments.



Comment at: clang/unittests/Format/FormatTest.cpp:22584
+  Style.Macros.push_back("CALL(x)=f([] { x })");
+  Style.Macros.push_back("ASSIGN_OR_RETURN(a, b, c)=a = (b) || (c)");
+

sammccall wrote:
> klimek wrote:
> > sammccall wrote:
> > > If this is assign_or_return, the treatment of "c" is fairly strange. Also 
> > > you are mostly calling this with only two args. Maybe drop C and use a 
> > > different macro for the 3-arg case?
> > ASSIGN_OR_RETURN allows 3 args, though; this is basically the thing I'd 
> > propose to configure for ASSIGN_OR_RETURN in general; is there anything 
> > specific you don't like about this?
> OK, this is a bit sticky.
>  - `ASSIGN_OR_RETURN` is almost always called with two args
>  - some versions of `ASSIGN_OR_RETURN` support an optional third arg (there's 
> no canonical public version)
>  - these emulate overloading using variadic macro tricks
>  - this patch doesn't claim to support either variadic macros or overloading
> 
> So the principled options seem to be:
>  - macros have fixed arity: clang-format can support the two-arg version of 
> `ASSIGN_OR_RETURN` but not the three-arg version. (This is what I was 
> assuming)
>  - macros have variable arity: the public docs need to describe how passing 
> too many/too few args is treated, because this isn't obvious and it sounds 
> like we want people to rely on it. This feels like stretching "principled" to 
> me - we're relying on the expansion still parsing correctly when args are 
> missing, which basically seems like coincidence.
>  - macros support overloading: instead of looking up macros by name, the key 
> is `(string Name, optional Arity)`
Chose option 3, as this is pretty straight-forward and I believe the best user 
experience.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144170

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

[PATCH] D144713: [Tooling/Includsion] Add the missing NULL symbol to the table.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
hokein added a reviewer: kadircet.
Herald added a project: All.
hokein requested review of this revision.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144713

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc


Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -237,3 +237,19 @@
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.
 SYMBOL(get, std::, /*no headers*/)
+
+// Macros
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )


Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -237,3 +237,19 @@
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.
 SYMBOL(get, std::, /*no headers*/)
+
+// Macros
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D144713: [Tooling/Includsion] Add the missing NULL symbol to the table.

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc:242
+// Macros
+SYMBOL(NULL, , )
+SYMBOL(NULL, , )

we use `None` for global namespace rather than leaving empty. let's keep it 
that way?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144713

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

[PATCH] D144713: [Tooling/Includsion] Add the missing NULL symbol to the table.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 500126.
hokein added a comment.

oops, fix the patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144713

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc


Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -237,3 +237,19 @@
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.
 SYMBOL(get, std::, /*no headers*/)
+
+// Macros
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )


Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -237,3 +237,19 @@
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.
 SYMBOL(get, std::, /*no headers*/)
+
+// Macros
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D144713: [Tooling/Includsion] Add the missing NULL symbol to the table.

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144713

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

[PATCH] D144273: [clang][ASTImporter] Add VaList declaration to lookup table.

[Donát Nagy via Phabricator via cfe-commits]

donat.nagy added a comment.

@balazske Thanks for clarifying the side effects of the current solution and I 
support creating that side-effect-free getter function -- it sounds to be a 
good solution for this problem. One minor doubt: I can theoretically imagine 
the case when the TU object doesn't contain the VaList declaration yet when the 
constructor of ASTImporterLookupTable is called (so the side-effect-free call 
does nothing), but then it somehow creates duplicated decls by importing VaList 
twice (e.g. via two imports)? (I think this is unlikely, but I'm unfamiliar 
with the usage patterns of ASTImporterLookupTable, so it'd be easier for you to 
verify that this kind of failure can't happen.)

Also consider renaming the current `getVaListTagDecl` to e.g. 
`getOrCreateVaListTagDecl` (it wouldn't blow up the commit size, there are only 
six references to it in the whole repo) and reusing the name `getVaListTagDecl` 
for the side-effect-free getter variant. (The `...IfExists` name variant is 
also acceptable and there are some precedents for it in the codebase, but I 
think it'd be less surprising on the long term if we reduced the amount of 
innocent-looking `getSomething` functions that are mutating our state.)

I still think it'd be good extend the patch with the "can we import `int std`" 
testcase(s), just to be sure. (Although obviously there is no need to run them 
on the current implementation if you think they'll fail and you already have an 
alternative solution.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144273

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

[PATCH] D144709: [clang-format] Improve west to east const

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

Can you please add unit tests for the cases you added


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144709

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

[clang] c86f05d - [Tooling/Inclusion] Add the missing NULL symbol to the table.

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2023-02-24T12:59:52+01:00
New Revision: c86f05dd48d2efc5d1bb7c9962ba331653311795

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

LOG: [Tooling/Inclusion] Add the missing NULL symbol to the table.

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

Added: 


Modified: 
clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc

Removed: 




diff  --git a/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc 
b/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
index 119952be6fe3..90a9aa9899fa 100644
--- a/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ b/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -237,3 +237,19 @@ SYMBOL(ssize, std::, )
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.
 SYMBOL(get, std::, /*no headers*/)
+
+// Macros
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )



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

[PATCH] D144713: [Tooling/Includsion] Add the missing NULL symbol to the table.

[Haojian Wu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
hokein marked an inline comment as done.
Closed by commit rGc86f05dd48d2: [Tooling/Inclusion] Add the missing NULL 
symbol to the table. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144713

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc


Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -237,3 +237,19 @@
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.
 SYMBOL(get, std::, /*no headers*/)
+
+// Macros
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )


Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -237,3 +237,19 @@
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.
 SYMBOL(get, std::, /*no headers*/)
+
+// Macros
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
+SYMBOL(NULL, None, )
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D143560: clang-format.el: fix warnings

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added subscribers: rymiel, HazardyKnusperkeks, owenpan, 
MyDeveloperDay.
MyDeveloperDay added a comment.

I'm one of the code owners for clang-format, but I'm not an emacs user (don't 
hate me..), honestly I don't think you'll get a response from anyone others 
than the clang-format team @owenpan, @HazardyKnusperkeks , @rymiel etc.. but 
again I can't say if they are emacs users.

If its been accepted by others we can land it.


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

https://reviews.llvm.org/D143560

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

[PATCH] D143560: clang-format.el: fix warnings

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

please mark the comments as done when you've addressed them


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

https://reviews.llvm.org/D143560

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

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

[Sam McCall via Phabricator via cfe-commits]

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

Great!

The overloading impl is a little surprising to me.
I was assuming that object would always win over function (or that it would be 
disallowed to combine the two).
I think that is simpler to implement, as you know in advance what type of 
expansion you're attempting.
But what you have isn't that much more complicated, and the extra flexibility 
may prove useful.

One weird side-effect: if you define an object-like macro FOO and then write 
`FOO(` and never close the paren, then we die inside macro-arg-parsing rather 
than hitting the normal EOF-while-formatting behavior. I left a comment on 
parseMacroCall() about how to fix this but I'm not sure whether it matters at a 
high level.




Comment at: clang/lib/Format/MacroExpander.cpp:172
   assert(defined(ID->TokenText));
+  assert(
+  (!OptionalArgs && ObjectLike.find(ID->TokenText) != ObjectLike.end()) ||

this assertion failure isn't going to be as useful as it could be!

maybe rather
```
if (OptionalArgs)
  assert(...);
else
  assert(...);
```

Also I think we're now ensuring to only call this if arity matches, so I'd make 
this a precondition and replace the first assert with hasArity to make it 
easier to reason about



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:4580
+  LLVM_DEBUG({
+llvm::dbgs() << "Call: " << ID->TokenText << "(";
+if (Args) {

nit: call => Macro call in dbgs()?



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:4592
+  !Macros.hasArity(ID->TokenText, Args->size())) {
+// The macro is overloaded to be both object-like and function-like,
+// but none of the function-like arities match the number of arguments.

Strictly I don't think this comment is true, we hit this path when it's 
**only** an object-like macro, used before parens.

For this reason you might *not* want the dbgs() here but rather in the bottom 
`else`



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:4610
+Unexpanded[ID] = std::move(UnexpandedLine);
+SmallVector New = Macros.expand(ID, Args);
+if (!New.empty())

(nit: std::move(args)?)



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:4610
+Unexpanded[ID] = std::move(UnexpandedLine);
+SmallVector New = Macros.expand(ID, Args);
+if (!New.empty())

sammccall wrote:
> (nit: std::move(args)?)
nit: maybe "expansion" is more descriptive than "new"?



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:4620
+});
+  } else {
+Tokens->setPosition(Position);

I think you may want a comment and/or dbgs() here explaining this case: `Didn't 
expand macro FOO because it was used {with 3|without} args, which doesn't match 
any definition`



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:4696
+  } while (!eof());
+  return {};
+}

I believe this has changed meaning along with the return type: previously it 
returned an empty vector, now it returns `nullopt`. Not sure which you intend 
here.

I think the ideal thing here would be to **rewind the token stream back to 
before the `(`**, and return `nullopt`. We'll end up performing an object-like 
substitution if possible, and non-macro parsing will continue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144170

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

[PATCH] D144721: [Tooling/Inclusion] Add the generic abs symbol to the table.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
hokein added a reviewer: kadircet.
Herald added a project: All.
hokein requested review of this revision.
Herald added a project: clang.

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144721

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc


Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -233,6 +233,15 @@
 SYMBOL(ssize, std::, )
 SYMBOL(ssize, std::, )
 
+// Add headers for generic integer-type abs.
+// Ignore other variants (std::complex, std::valarray, std::intmax_t)
+SYMBOL(abs, std::, )
+SYMBOL(abs, std::, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+
 // std::get has a few variants for different types (tuple, array, pair etc)
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.


Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -233,6 +233,15 @@
 SYMBOL(ssize, std::, )
 SYMBOL(ssize, std::, )
 
+// Add headers for generic integer-type abs.
+// Ignore other variants (std::complex, std::valarray, std::intmax_t)
+SYMBOL(abs, std::, )
+SYMBOL(abs, std::, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+
 // std::get has a few variants for different types (tuple, array, pair etc)
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D144709: [clang-format] Improve west to east const

[Alexander Hederstaf via Phabricator via cfe-commits]

AlexanderHederstaf added a comment.

I will add new tests / examples as well as look into the volatile/const 
ordering.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144709

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

[PATCH] D143496: [clangd] Add support for missing includes analysis.

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

thanks! looks amazing, we're missing a little bit of test coverage though




Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:280
 
+bool isFilteredByConfig(const Config &Cfg, llvm::StringRef HeaderSpelling) {
+  // Convert the path to Unix slashes and try to match against the filter.

s/HeaderSpelling/HeaderPath



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:282
+  // Convert the path to Unix slashes and try to match against the filter.
+  llvm::SmallString<64> Path(HeaderSpelling);
+  llvm::sys::path::native(Path, llvm::sys::path::Style::posix);

s/Path/NormalizedPath



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:414
+
+std::string findResolvedPath(const include_cleaner::Header &SymProvider) {
+  std::string ResolvedPath;

what about just `resolvedPath`, if you'd rather keep the verb, i think `get` 
makes more sense than `find`. we're not really searching anything.



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:418
+  case include_cleaner::Header::Physical:
+ResolvedPath = SymProvider.physical()->tryGetRealPathName();
+break;

nit: you can directly `return  SymProvider.physical()->tryGetRealPathName();` 
(same for other 2 cases) and have an `llvm_unreachable("Unknown symbol kind");` 
after the switch statement.



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:421
+  case include_cleaner::Header::Standard:
+ResolvedPath = SymProvider.standard().name();
+break;

in this and the next case we need to trim `<>"`



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:430
+
+std::string findSymbolName(const include_cleaner::Symbol &Sym) {
+  std::string SymbolName;

same as above, either just `symbolName` or `get`



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:434
+  case include_cleaner::Symbol::Macro:
+SymbolName = Sym.macro().Name->getName();
+break;

again you can just return here and below



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:434
+  case include_cleaner::Symbol::Macro:
+SymbolName = Sym.macro().Name->getName();
+break;

kadircet wrote:
> again you can just return here and below
`getName` is a StringRef, and unfortunately there are some platforms (like 
darwin) that don't support implicit conversion from stringrefs to std::string. 
so can you call `.str()` explicitly in the end?



Comment at: clang-tools-extra/clangd/IncludeCleaner.cpp:754
+  IncludeCleanerFindings Findings;
+  if (Cfg.Diagnostics.MissingIncludes != Config::IncludesPolicy::None ||
+  Cfg.Diagnostics.UnusedIncludes != Config::IncludesPolicy::None) {

i think for now this should be
```
if (Cfg.Diagnostics.MissingIncludes == Config::IncludesPolicy::Strict ||
  Cfg.Diagnostics.UnusedIncludes == Config::IncludesPolicy::Experiment) {
```

otherwise we'll run both legacy and new analysis for `UnusedIncludes == Strict`



Comment at: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp:449
+include_cleaner::Symbol B{*D};
+syntax::FileRange BRange{SM, B.declaration().getBeginLoc(), 1};
+include_cleaner::Header Header{*SM.getFileManager().getFile("b.h")};

this is pointing at the declaration inside `b.h` not to the reference inside 
the main file. are you sure this test passes?



Comment at: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp:469
+  $d[[d]]();
+  $f[[f]]();
+})cpp");

can you also add a reference (and declaration) for std::vector, and have an 
IWYU private pragma in one of the headers to test code paths that spell 
verbatim and standard headers? also having some diagnostic suppressed via 
`IgnoreHeaders` is important to check



Comment at: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp:481
+  TU.AdditionalFiles["system/e.h"] = guard("#include ");
+  TU.AdditionalFiles["system/f.h"] = guard("void f();");
+  TU.ExtraArgs.push_back("-isystem" + testPath("system"));

can you make one of these names qualified? e.g. `namespace ns { struct Bar { 
void f(); }; }`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143496

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

[PATCH] D144721: [Tooling/Inclusion] Add the generic abs symbol to the table.

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

this fixes the `abs` in the mentioned issue, but leaves the friends out :( 
those are specifically `std::labs, std::llabs, std::imaxabs`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144721

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

[PATCH] D144721: [Tooling/Inclusion] Add the generic abs symbol to the table.

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

In D144721#4150122 , @kadircet wrote:

> this fixes the `abs` in the mentioned issue, but leaves the friends out :( 
> those are specifically `std::labs, std::llabs, std::imaxabs`

These symbols are already covered in the generated `StdSymbolMap.inc` file :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144721

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

[PATCH] D144721: [Tooling/Inclusion] Add the generic abs symbol to the table.

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

oh right, i thought these were also provided by multiple headers, but looks 
like they're only provided by `cstdlib`, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144721

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

[clang-tools-extra] 6b0cf1e - [clang-tidy] handle exceptions properly in `ExceptionAnalyzer`

[via cfe-commits]

Author: isuckatcs
Date: 2023-02-24T13:46:47+01:00
New Revision: 6b0cf1e15f8f84e3d4b6f9522287f6460527a7bf

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

LOG: [clang-tidy] handle exceptions properly in `ExceptionAnalyzer`

This patch implements the exception handling rules found in
N4849 14.4 and as a result fixes many false positives in
the bugprone-exception-escape checker.

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.cpp
clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.h
clang-tools-extra/test/clang-tidy/checkers/bugprone/exception-escape.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.cpp 
b/clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.cpp
index 359e7e9dc46af..251d78e21a330 100644
--- a/clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.cpp
+++ b/clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.cpp
@@ -44,7 +44,56 @@ ExceptionAnalyzer::ExceptionInfo 
&ExceptionAnalyzer::ExceptionInfo::merge(
   return *this;
 }
 
-static bool isBaseOf(const Type *DerivedType, const Type *BaseType) {
+// FIXME: This could be ported to clang later.
+namespace {
+
+bool isUnambiguousPublicBaseClass(const Type *DerivedType,
+  const Type *BaseType) {
+  const auto *DerivedClass =
+  DerivedType->getCanonicalTypeUnqualified()->getAsCXXRecordDecl();
+  const auto *BaseClass =
+  BaseType->getCanonicalTypeUnqualified()->getAsCXXRecordDecl();
+  if (!DerivedClass || !BaseClass)
+return false;
+
+  CXXBasePaths Paths;
+  Paths.setOrigin(DerivedClass);
+
+  bool IsPublicBaseClass = false;
+  DerivedClass->lookupInBases(
+  [&BaseClass, &IsPublicBaseClass](const CXXBaseSpecifier *BS,
+   CXXBasePath &) {
+if (BS->getType()
+->getCanonicalTypeUnqualified()
+->getAsCXXRecordDecl() == BaseClass &&
+BS->getAccessSpecifier() == AS_public) {
+  IsPublicBaseClass = true;
+  return true;
+}
+
+return false;
+  },
+  Paths);
+
+  return !Paths.isAmbiguous(BaseType->getCanonicalTypeUnqualified()) &&
+ IsPublicBaseClass;
+}
+
+inline bool isPointerOrPointerToMember(const Type *T) {
+  return T->isPointerType() || T->isMemberPointerType();
+}
+
+QualType getPointeeOrArrayElementQualType(QualType T) {
+  if (T->isAnyPointerType())
+return T->getPointeeType();
+
+  if (T->isArrayType())
+return T->getAsArrayTypeUnsafe()->getElementType();
+
+  return T;
+}
+
+bool isBaseOf(const Type *DerivedType, const Type *BaseType) {
   const auto *DerivedClass = DerivedType->getAsCXXRecordDecl();
   const auto *BaseClass = BaseType->getAsCXXRecordDecl();
   if (!DerivedClass || !BaseClass)
@@ -54,11 +103,264 @@ static bool isBaseOf(const Type *DerivedType, const Type 
*BaseType) {
   [BaseClass](const CXXRecordDecl *Cur) { return Cur != BaseClass; });
 }
 
-bool ExceptionAnalyzer::ExceptionInfo::filterByCatch(const Type *BaseClass) {
+// Check if T1 is more or Equally qualified than T2.
+bool moreOrEquallyQualified(QualType T1, QualType T2) {
+  return T1.getQualifiers().isStrictSupersetOf(T2.getQualifiers()) ||
+ T1.getQualifiers() == T2.getQualifiers();
+}
+
+bool isStandardPointerConvertible(QualType From, QualType To) {
+  assert((From->isPointerType() || From->isMemberPointerType()) &&
+ (To->isPointerType() || To->isMemberPointerType()) &&
+ "Pointer conversion should be performed on pointer types only.");
+
+  if (!moreOrEquallyQualified(To->getPointeeType(), From->getPointeeType()))
+return false;
+
+  // (1)
+  // A null pointer constant can be converted to a pointer type ...
+  // The conversion of a null pointer constant to a pointer to cv-qualified 
type
+  // is a single conversion, and not the sequence of a pointer conversion
+  // followed by a qualification conversion. A null pointer constant of 
integral
+  // type can be converted to a prvalue of type std::nullptr_t
+  if (To->isPointerType() && From->isNullPtrType())
+return true;
+
+  // (2)
+  // A prvalue of type “pointer to cv T”, where T is an object type, can be
+  // converted to a prvalue of type “pointer to cv void”.
+  if (To->isVoidPointerType() && From->isObjectPointerType())
+return true;
+
+  // (3)
+  // A prvalue of type “pointer to cv D”, where D is a complete class type, can
+  // be converted to a prvalue of type “pointer to cv B”, where B is a base
+  // class of D. If B is an inaccessible or ambiguous base class of D, a 
program
+  // that necessitates this conversion is ill-formed.
+  if (const auto *RD = From->getPointeeCXXRecordDecl()) {
+if (RD-

[PATCH] D135495: [clang-tidy] handle exceptions properly in `ExceptionAnalyzer`

[Domján Dániel via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG6b0cf1e15f8f: [clang-tidy] handle exceptions properly in 
`ExceptionAnalyzer` (authored by isuckatcs).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135495

Files:
  clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.cpp
  clang-tools-extra/clang-tidy/utils/ExceptionAnalyzer.h
  clang-tools-extra/test/clang-tidy/checkers/bugprone/exception-escape.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone/exception-escape.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone/exception-escape.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone/exception-escape.cpp
@@ -101,6 +101,126 @@
   }
 }
 
+void throw_catch_pointer_c() noexcept {
+  try {
+int a = 1;
+throw &a;
+  } catch(const int *) {}
+}
+
+void throw_catch_pointer_v() noexcept {
+  try {
+int a = 1;
+throw &a;
+  } catch(volatile int *) {}
+}
+
+void throw_catch_pointer_cv() noexcept {
+  try {
+int a = 1;
+throw &a;
+  } catch(const volatile int *) {}
+}
+
+void throw_catch_multi_ptr_1() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_catch_multi_ptr_1' which should not throw exceptions
+  try {
+char **p = 0;
+throw p;
+  } catch (const char **) {
+  }
+}
+
+void throw_catch_multi_ptr_2() noexcept {
+  try {
+char **p = 0;
+throw p;
+  } catch (const char *const *) {
+  }
+}
+
+void throw_catch_multi_ptr_3() noexcept {
+  try {
+char **p = 0;
+throw p;
+  } catch (volatile char *const *) {
+  }
+}
+
+void throw_catch_multi_ptr_4() noexcept {
+  try {
+char **p = 0;
+throw p;
+  } catch (volatile const char *const *) {
+  }
+}
+
+// FIXME: In this case 'a' is convertible to the handler and should be caught
+// but in reality it's thrown. Note that clang doesn't report a warning for 
+// this either.
+void throw_catch_multi_ptr_5() noexcept {
+  try {
+double *a[2][3];
+throw a;
+  } catch (double *(*)[3]) {
+  }
+}
+
+
+void throw_c_catch_pointer() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_c_catch_pointer' which should not throw exceptions
+  try {
+int a = 1;
+const int *p = &a;
+throw p;
+  } catch(int *) {}
+}
+
+void throw_c_catch_pointer_v() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_c_catch_pointer_v' which should not throw exceptions
+  try {
+int a = 1;
+const int *p = &a;
+throw p;
+  } catch(volatile int *) {}
+}
+
+void throw_v_catch_pointer() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_v_catch_pointer' which should not throw exceptions
+  try {
+int a = 1;
+volatile int *p = &a;
+throw p;
+  } catch(int *) {}
+}
+
+void throw_v_catch_pointer_c() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_v_catch_pointer_c' which should not throw exceptions
+  try {
+int a = 1;
+volatile int *p = &a;
+throw p;
+  } catch(const int *) {}
+}
+
+void throw_cv_catch_pointer_c() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_cv_catch_pointer_c' which should not throw exceptions
+  try {
+int a = 1;
+const volatile int *p = &a;
+throw p;
+  } catch(const int *) {}
+}
+
+void throw_cv_catch_pointer_v() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_cv_catch_pointer_v' which should not throw exceptions
+  try {
+int a = 1;
+const volatile int *p = &a;
+throw p;
+  } catch(volatile int *) {}
+}
+
 class base {};
 class derived: public base {};
 
@@ -112,6 +232,229 @@
   }
 }
 
+void throw_derived_alias_catch_base() noexcept {
+  using alias = derived;
+
+  try {
+throw alias();
+  } catch(base &) {
+  }
+}
+
+void throw_derived_catch_base_alias() noexcept {
+  using alias = base;
+
+  try {
+throw derived();
+  } catch(alias &) {
+  }
+}
+
+void throw_derived_catch_base_ptr_c() noexcept {
+  try {
+derived d;
+throw &d; 
+  } catch(const base *) {
+  }
+}
+
+void throw_derived_catch_base_ptr() noexcept {
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: an exception may be thrown in function 'throw_derived_catch_base_ptr' which should not throw exceptions
+  try {
+derived d;
+const derived *p = &d;
+throw p; 
+  } catch(base *) {
+  }
+}
+
+class A {};
+class B : A {};
+
+// The following alias hell is deliberately created for testing.
+using aliasedA = A;
+class C : protected aliasedA {};
+
+typedef aliasedA moreAliasedA;
+class D : public moreAliasedA {};
+
+using moreMoreAliasedA = moreAliasedA;
+using aliasedD = D;
+class E : pub

[PATCH] D124351: [Clang] Implement Change scope of lambda trailing-return-type

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin added a comment.

@rupprecht Great to hear! Sorry again for the disruption
@shafik Thanks  for the review!




Comment at: clang/lib/Sema/SemaLambda.cpp:1010
+
+  // C++11 [expr.prim.lambda]p5:
+  //   The closure type for a lambda-expression has a public inline function

shafik wrote:
> Same as comment above about updating wording to reflect C++20.
I don't even think we should repeat that comment here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124351

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

[clang] 4416e4a - [Tooling/Inclusion] Add the generic abs symbol to the table.

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2023-02-24T13:56:00+01:00
New Revision: 4416e4a9ed0666cbeb3d34f43337d7205c09521a

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

LOG: [Tooling/Inclusion] Add the generic abs symbol to the table.

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

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

Added: 


Modified: 
clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc

Removed: 




diff  --git a/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc 
b/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
index 90a9aa9899fa2..692f61a45e6f4 100644
--- a/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ b/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -233,6 +233,15 @@ SYMBOL(ssize, std::, )
 SYMBOL(ssize, std::, )
 SYMBOL(ssize, std::, )
 
+// Add headers for generic integer-type abs.
+// Ignore other variants (std::complex, std::valarray, std::intmax_t)
+SYMBOL(abs, std::, )
+SYMBOL(abs, std::, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+
 // std::get has a few variants for 
diff erent types (tuple, array, pair etc)
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.



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

[PATCH] D144721: [Tooling/Inclusion] Add the generic abs symbol to the table.

[Haojian Wu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4416e4a9ed06: [Tooling/Inclusion] Add the generic abs symbol 
to the table. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144721

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc


Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -233,6 +233,15 @@
 SYMBOL(ssize, std::, )
 SYMBOL(ssize, std::, )
 
+// Add headers for generic integer-type abs.
+// Ignore other variants (std::complex, std::valarray, std::intmax_t)
+SYMBOL(abs, std::, )
+SYMBOL(abs, std::, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+
 // std::get has a few variants for different types (tuple, array, pair etc)
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.


Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -233,6 +233,15 @@
 SYMBOL(ssize, std::, )
 SYMBOL(ssize, std::, )
 
+// Add headers for generic integer-type abs.
+// Ignore other variants (std::complex, std::valarray, std::intmax_t)
+SYMBOL(abs, std::, )
+SYMBOL(abs, std::, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+SYMBOL(abs, None, )
+
 // std::get has a few variants for different types (tuple, array, pair etc)
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D144684: [clang][Driver] Pass /INFERASANLIBS:NO to link.exe under -fsanitize=address

[Hans Wennborg via Phabricator via cfe-commits]

hans accepted this revision.
hans 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/D144684/new/

https://reviews.llvm.org/D144684

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

[PATCH] D144218: [Clang] [AVR] Fix USHRT_MAX for 16-bit int.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added reviewers: jyknight, clang-language-wg.
aaron.ballman added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:43-45
+- The definition of ``USHRT_MAX`` in the freestanding  no longer
+  overflows on AVR (where ``sizeof(unsigned int) == sizeof(unsigned short)``).
+  The type of ``USHRT_MAX`` on AVR is now ``unsigned int`` instead of ``int``,

I'd be surprised if this actually has much of a chance to break people. I'd 
probably put this under a new AVR section under `Target Specific Changes`, WDYT?



Comment at: clang/lib/Headers/limits.h:55
 #define UCHAR_MAX (__SCHAR_MAX__*2  +1)
-#define USHRT_MAX (__SHRT_MAX__ *2  +1)
+#if __SHRT_MAX__ * 2U + 1U <= __INT_MAX__
+#define USHRT_MAX (__SHRT_MAX__ * 2 + 1)

Rather than do math here, WDYT about using the WIDTH macros? It seems like a 
more direct comparison:
```
#if __SHRT_WIDTH__ == __INT_WIDTH__
#endif
```
(This also makes me wonder if we have any targets where we need to do this with 
`UCHAR_MAX` as well. IIRC, we only support `CHAR_BIT` == 8 and so we're 
probably fine, but might as well double-check since we're fixing this kind of 
mistake.)



Comment at: clang/lib/Headers/limits.h:55
 #define UCHAR_MAX (__SCHAR_MAX__*2  +1)
-#define USHRT_MAX (__SHRT_MAX__ *2  +1)
+#define USHRT_MAX (__SHRT_MAX__ * 2U + 1U)
 #define UINT_MAX  (__INT_MAX__  *2U +1U)

mysterymath wrote:
> aaron.ballman wrote:
> > mysterymath wrote:
> > > aaron.ballman wrote:
> > > > It's worth double-checking that this still gives the correct type for 
> > > > the macro:
> > > > 
> > > > C2x 5.2.4.2.1p2: For all unsigned integer types for which  or 
> > > >  define a macro with suffix _WIDTH holding its width N, there 
> > > > is a macro with suffix _MAX holding the maximal value 2N − 1 that is 
> > > > representable by the type and that has the same type as would an 
> > > > expression that is an object of the corresponding type converted 
> > > > according to the integer promotions. ...
> > > Ah, thanks; it hadn't occurred to me that the type of the expression 
> > > would be specified in the standard. It could be either `unsigned int` or 
> > > `int`, depending on the target.
> > > 
> > > The most straightforward approach I could think of to produce the right 
> > > type is:
> > > 1) Perform the arithmetic in `unsigned int` to produce the right value
> > > 2) Cast to `unsigned short` to produce the right type
> > > 3) Directly perform integer promotion using unary plus
> > > 
> > > The use of unary plus is a bit odd here, but it seems like the most 
> > > direct way to express the logic, and the overall expression seems less 
> > > fragile than the `#if` alternative. I've added a comment to explain this 
> > > as well.
> > Now the trouble is with the cast operation, because that runs afoul of 
> > 5.2.4.2.1p1: The values given below shall be replaced by constant 
> > expressions suitable for use in conditional expression inclusion 
> > preprocessing directives. ...
> > 
> > https://godbolt.org/z/K9cs66sdK
> > 
> > I'm almost wondering if the most direct solution is for `__SHRT_MAX__` to 
> > be generated with or without the `U` suffix depending on target.
> > 
> > We should probably use this as an opportunity to add more exhaustive 
> > testing for all the _MIN and _MAX macros to ensure the type properties 
> > hold. I was playing around with something like this: 
> > https://godbolt.org/z/o7KjY3asW
> > Now the trouble is with the cast operation, because that runs afoul of 
> > 5.2.4.2.1p1: The values given below shall be replaced by constant 
> > expressions suitable for use in conditional expression inclusion 
> > preprocessing directives. ...
> > 
> > https://godbolt.org/z/K9cs66sdK
> > 
> Sigh, it appears my standards-fu is not strong. I'm rather surprised to find 
> that you can't cast to an integer type in `#if`; 6.10.1.6 claim they take a 
> `constant-expression`, evaluated according to 6.6. But I can't find anything 
> in 6.6 that seems to exclude cast operators. The definition of integer 
> constant expressions even specifically calls out casts to integer types, 
> although it doesn't specifically say in 6.10.1.6 that it takes an integer 
> constant expression.
> Would you happen to know off-hand what my mistake is?
> 
> I think the `#if` version I had originally isn't subject to this; I'll switch 
> back to that. 
> 
> > I'm almost wondering if the most direct solution is for `__SHRT_MAX__` to 
> > be generated with or without the `U` suffix depending on target.
> Seems like that wouldn't work for the more straightforward case of `#define 
> SHRT_MAX __SHRT_MAX__`; the type of this must always be int, since SHRT_MAX 
> is always representable in int, even on 16-bit targets.
>  
> > We should probably use this as an opportunity to add more exhaustive 
> > testing for all the _MIN and _MAX macros to ensure the type properties 
> > hold. I was playing

[PATCH] D143287: [Clang][X86] Change X86 cast intrinsics to use __builtin_nondeterministic_value

[Manuel Brito via Phabricator via cfe-commits]

ManuelJBrito updated this revision to Diff 500149.
ManuelJBrito added a comment.

Update tests after D143593 .

There are some performance regressions with casts from 128 to 512. The backend 
inserts vinsertf instructions. So that as to be fixed.
In D130339  @RKSimon  mentioned something 
about custom vector widening patterns that need to be adjusted to handle 
freeze(undef), any pointers for how a patch for that would look like?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143287

Files:
  clang/lib/Headers/avx512fintrin.h
  clang/lib/Headers/avx512fp16intrin.h
  clang/lib/Headers/avxintrin.h
  clang/test/CodeGen/X86/avx-builtins.c
  clang/test/CodeGen/X86/avx-cast-builtins.c
  clang/test/CodeGen/X86/avx512f-builtins.c
  clang/test/CodeGen/X86/avx512fp16-builtins.c

Index: clang/test/CodeGen/X86/avx512fp16-builtins.c
===
--- clang/test/CodeGen/X86/avx512fp16-builtins.c
+++ clang/test/CodeGen/X86/avx512fp16-builtins.c
@@ -325,19 +325,22 @@
 
 __m256h test_mm256_castph128_ph256(__m128h __a) {
   // CHECK-LABEL: test_mm256_castph128_ph256
-  // CHECK: shufflevector <8 x half> %{{.*}}, <8 x half> %{{.*}}, <16 x i32> 
+  // CHECK: [[A:%.*]] = freeze <8 x half> poison
+  // CHECK: shufflevector <8 x half> %{{.*}}, <8 x half> [[A]], <16 x i32> 
   return _mm256_castph128_ph256(__a);
 }
 
 __m512h test_mm512_castph128_ph512(__m128h __a) {
   // CHECK-LABEL: test_mm512_castph128_ph512
-  // CHECK: shufflevector <8 x half> %{{.*}}, <8 x half> %{{.*}}, <32 x i32> 
+  // CHECK: [[A:%.*]] = freeze <8 x half> poison
+  // CHECK: shufflevector <8 x half> %{{.*}}, <8 x half> [[A]], <32 x i32> 
   return _mm512_castph128_ph512(__a);
 }
 
 __m512h test_mm512_castph256_ph512(__m256h __a) {
   // CHECK-LABEL: test_mm512_castph256_ph512
-  // CHECK: shufflevector <16 x half> %{{.*}}, <16 x half> %{{.*}}, <32 x i32> 
+  // CHECK: [[A:%.*]] = freeze <16 x half> poison
+  // CHECK: shufflevector <16 x half> %{{.*}}, <16 x half> [[A]], <32 x i32> 
   return _mm512_castph256_ph512(__a);
 }
 
Index: clang/test/CodeGen/X86/avx512f-builtins.c
===
--- clang/test/CodeGen/X86/avx512f-builtins.c
+++ clang/test/CodeGen/X86/avx512f-builtins.c
@@ -8987,13 +8987,15 @@
 
 __m512 test_mm512_castps128_ps512(__m128 __A) {
   // CHECK-LABEL: @test_mm512_castps128_ps512
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <16 x i32> 
+  // CHECK: [[A:%.*]] = freeze <4 x float> poison
+  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> [[A]], <16 x i32> 
   return _mm512_castps128_ps512(__A); 
 }
 
 __m512d test_mm512_castpd128_pd512(__m128d __A) {
   // CHECK-LABEL: @test_mm512_castpd128_pd512
-  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> %{{.*}}, <8 x i32> 
+  // CHECK: [[A:%.*]] = freeze <2 x double> poison
+  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> [[A]], <8 x i32> 
   return _mm512_castpd128_pd512(__A); 
 }
 
@@ -9086,7 +9088,8 @@
 __m512d test_mm512_castpd256_pd512(__m256d a)
 {
   // CHECK-LABEL: @test_mm512_castpd256_pd512
-  // CHECK: shufflevector <4 x double> {{.*}} 
+  // CHECK: [[A:%.*]] = freeze <4 x double> poison
+  // CHECK: shufflevector <4 x double> {{.*}}, <4 x double> [[A]], <8 x i32> 
   return _mm512_castpd256_pd512(a);
 }
 
@@ -9112,13 +9115,15 @@
 }
 __m512i test_mm512_castsi128_si512(__m128i __A) {
   // CHECK-LABEL: @test_mm512_castsi128_si512
-  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <8 x i32> 
+  // CHECK: [[A:%.*]] = freeze <2 x i64> poison
+  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> [[A]], <8 x i32> 
   return _mm512_castsi128_si512(__A); 
 }
 
 __m512i test_mm512_castsi256_si512(__m256i __A) {
   // CHECK-LABEL: @test_mm512_castsi256_si512
-  // CHECK: shufflevector <4 x i64> %{{.*}}, <4 x i64> %{{.*}}, <8 x i32> 
+  // CHECK: [[A:%.*]] = freeze <4 x i64> poison
+  // CHECK: shufflevector <4 x i64> %{{.*}}, <4 x i64> [[A]], <8 x i32> 
   return _mm512_castsi256_si512(__A); 
 }
 
Index: clang/test/CodeGen/X86/avx-cast-builtins.c
===
--- /dev/null
+++ clang/test/CodeGen/X86/avx-cast-builtins.c
@@ -0,0 +1,112 @@
+// RUN: %clang_cc1 %s -O3 -flax-vector-conversions=none -ffreestanding %s -triple=x86_64-unknown-unknown -target-feature +avx -target-feature +avx512f  -target-feature +avx512fp16 -S -o - | FileCheck %s
+
+
+#include 
+
+__m256d test_mm256_castpd128_pd256(__m128d A) {
+  // CHECK-LABEL: test_mm256_castpd128_pd256
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm256_castpd128_pd256(A);
+}
+
+__m256 test_mm256_castps128_ps256(__m128 A) {
+  // CHECK-LABEL: test_mm256_castps128_ps256
+  // C

[PATCH] D143524: Make the -Wunused-template default.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D143524#4148024 , @v.g.vassilev 
wrote:

> Indeed the warning is noisy but it will potentially fix broken code which 
> were unable to diagnose before. Especially that in some cases where static 
> templates in header files are used as an idiom. In theory this approach can 
> extend to cases described in https://wg21.link/p2691 where our inability to 
> diagnose/fix these cases leads to some design decisions which may not be 
> optimal.

We need to ensure the diagnostic is not so noisy that people disable it, 
though. That means a low false positive rate and a straight-forward way to 
silence the diagnostic on a case-by-case basis.




Comment at: clang/test/SemaCXX/warn-func-not-needed.cpp:13
 namespace test1_template {
-template  static void f() {}
+template  static void f() {} // expected-warning {{unused function 
template}}
 template <> void f() {} // expected-warning {{function 'f' is not 
needed and will not be emitted}}

v.g.vassilev wrote:
> aaron.ballman wrote:
> > Why is this unused? `f()` in `foo()` should cause this to be used, 
> > right?
> > 
> > How should a user silence this diagnostic without disabling it entirely?
> Nobody uses `foo`.
Ah, good point on `foo` not being used, but the question still stands -- how 
does the user silence this diagnostic? It's not at all uncommon to have a 
primary template with specializations where the TU only uses either the primary 
or a specialization, but not both (and certainly not all specializations).


Repository:
  rC Clang

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

https://reviews.llvm.org/D143524

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