[PATCH] D34654: Allow passing a regex for headers to exclude from clang-tidy

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

It would be great to get something like this in.

In our project we're currently using a kludge of overriding the 
`RULE_LAUNCH_COMPILE` CMake variable to insert our own shell script as the 
compiler. The script strips the clang-tidy invocation inserted by CMake if the 
source path matches any of a set of regexes we have in a .clang-tidy-exclude 
file.

The original suggested solution with an exclude regex would be sufficient for 
us, but the source-centric approach described by @alexfh would also work. Just 
something would be good.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D34654



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

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

@lebedev.ri @aaron.ballman I think the opt-in sounds good too. Are we waiting 
for @fiesh to implement this, or is the patch abandoned? Would be sad if it was 
stranded the way https://reviews.llvm.org/D31130 was, since I think many people 
are skipping this check due to diagnostics that are for all intents and 
purposes "out of their control".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

Sounds good @aaron.ballman, let's wait for @fiesh.

Though I realize now that the scope of this patch is probably not enough to 
solve a problem we have in our code base. The check will warn about (for 
example) things like this:

In a third party lib outside our control:

  void f(double out[3]);

In our code:

  double out[3];
  fn_in_third_party_lib(out);

Include paths for the third party lib are added with -isystem.

Am I right that we're still going to get warnings for this with this patch?

Full disclosure. The third party lib is VTK, which is littered with APIs like 
these.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

And there he is :) I've never worked on LLVM / clang-tidy but could have a look 
at making it opt-in. Now we know the status at least.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

@aaron.ballman A bit off topic, but I followed 
https://github.com/llvm/llvm-project/blob/main/README.md#getting-the-source-code-and-building-llvm
 to build and install llvm-project main branch as follows:

  git clone https://github.com/llvm/llvm-project.git
  cd llvm-project
  cmake -S llvm -B build -G Ninja -DLLVM_ENABLE_PROJECTS=clang-tools-extra 
-DCMAKE_INSTALL_PREFIX=/home/estan/orexplore/llvm-project-inst
  cmake --build build
  cmake --install build

But I did not get any clang-tidy in the build or installation directory. The 
CMake output said "clang-tools-extra project is enabled". Any tips on where I 
went wrong?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp:65
 void ProBoundsArrayToPointerDecayCheck::registerMatchers(MatchFinder *Finder) {
-  // The only allowed array to pointer decay
+  // We only allowed array to pointer decays
   // 1) just before array subscription




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

Ah yes I had a hunch it had to be "clang;clang-tools-extra" so running a build 
with that now. Almost done. It crashed at the very end due to OOM while 
linking, but reduced parallelism now and running again. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

That did the trick, thanks @aaron.ballman.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

@carlosgalvezp Oh yes, that would be even better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

In D88833#3222829 , @estan wrote:

> Sounds good @aaron.ballman, let's wait for @fiesh.
>
> Though I realize now that the scope of this patch is probably not enough to 
> solve a problem we have in our code base. The check will warn about (for 
> example) things like this:
>
> In a third party lib outside our control:
>
>   void f(double out[3]);
>
> In our code:
>
>   double out[3];
>   f(out);
>
> Include paths for the third party lib are added with -isystem.
>
> Am I right that we're still going to get warnings for this with this patch?
>
> Full disclosure. The third party lib is VTK, which is littered with APIs like 
> these.

@aaron.ballman BTW, would you guys be open to a patch that makes the check not 
warn in cases like the above, or at least an option to make it not warn?

We like the spirit of this check, to make sure we use gsl::array_view/std::span 
instead of (T *data, int size) style interfaces in our own APIs. But we cannot 
change the (T*) APIs of our third party libraries. Having to litter our code 
with hundreds of casts is not very nice. It would be great if there was an 
option to tell the check to ignore all decays that occur in calls to functions 
in system headers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

In D88833#3225842 , @aaron.ballman 
wrote:

> In D88833#3224389 , @carlosgalvezp 
> wrote:
>
>> Please note: I have a patch that disables warnings from system macros for 
>> all clang-tidy warnings, it would be good to review it so we don't need to 
>> implement the same mechanism in all 400+ checks :) 
>> https://reviews.llvm.org/D116378
>
> Thank you for pointing that out; that's a far better approach.
>
> In D88833#3224799 , @estan wrote:
>
>> In D88833#3222829 , @estan wrote:
>>
>>> Sounds good @aaron.ballman, let's wait for @fiesh.
>>>
>>> Though I realize now that the scope of this patch is probably not enough to 
>>> solve a problem we have in our code base. The check will warn about (for 
>>> example) things like this:
>>>
>>> In a third party lib outside our control:
>>>
>>>   void f(double out[3]);
>>>
>>> In our code:
>>>
>>>   double out[3];
>>>   f(out);
>>>
>>> Include paths for the third party lib are added with -isystem.
>>>
>>> Am I right that we're still going to get warnings for this with this patch?
>>>
>>> Full disclosure. The third party lib is VTK, which is littered with APIs 
>>> like these.
>
> Yes, you will still get warnings with that code.
>
>> @aaron.ballman BTW, would you guys be open to a patch that makes the check 
>> not warn in cases like the above, or at least an option to make it not warn?
>>
>> We like the spirit of this check, to make sure we use 
>> gsl::array_view/std::span instead of (T *data, int size)/(T*) style 
>> interfaces in our own APIs. But we cannot change the (T*) APIs of our third 
>> party libraries. Having to litter our code with hundreds of casts is not 
>> very nice. It would be great if there was an option to tell the check to 
>> ignore all decays that occur in calls to functions in system headers.
>
> You can't change the 3rd party APIs because they're system headers, but you 
> can add a cast to the call site to disable the diagnostic. Does that suffice 
> to meet your needs, or do you still think an option is a better approach? 
> https://godbolt.org/z/q41Wdn3xa

Well it's not just one call site, but a whole bunch of them, and having to add 
casts at all these places is a bit cumbersome. I think an option to only warn 
for cases where you can meaningfully improve the code (by changing the API to 
use std::span / gsl::array_view) would be good.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

Yep thanks a lot for that @carlosgalvezp, getting the system macros sorted out 
will get rid of many warnings we were getting in our code base (seems the 
qDebug / qWarning macros in the Qt version we're are using violate this check 
on their own).

Regarding decay in calls to functions in system headers, it's unfortunately 
many different functions involved, and often they are member functions of some 
class. VTK is an old slow-moving library and has many API functions like:

  void vtkInformation::Get(vtkInformationDoubleVectorKey* key, double* value);
  void vtkPiecewiseFunction::GetNodeValue(int index, double val[4]);
  void vtkCamera::GetPosition(double[3]);
  void vtkCamera::GetFocalPoint(double[3]);
  void vtkInteractorObserver::ComputeDisplayToWorld(double x, double y, double 
z, double worldPt[4]);
  ...

These were just some examples of functions we use in our code base, but VTK is 
full of APIs like these.

We also use the Qwt and ed25519 library, which have functions like:

  void QwtPlotCurve::setSamples(const float* xData, const float* yData, int 
size);
  int ed25519_verify(const unsigned char *signature, const unsigned char 
*message, size_t message_len, const unsigned char *public_key);
  ...

I don't think it's uncommon when working with libraries that are not modern C++ 
to run into a lot of APIs like these, so would be nice to be able to avoid the 
decay warning when calling into them, without sprinking casts and wrappers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

Alright, yea I'll see what using std::array would mean for our code. In many 
cases we are just using plain arrays currently, and often they are just a way 
to get data in/out of these APIs (and for the out direction, we quickly go on 
to saving the data we got out into something else, like a class of our own). 
I'll think some about it, perhaps you are right and the exception (would make 
it an option of course) is not worth it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D116814: Accept string literal decay in conditional operator

[Elvis Stansvik via Phabricator via cfe-commits]

estan created this revision.
Herald added subscribers: carlosgalvezp, kbarton, nemanjai.
estan edited the summary of this revision.
estan edited the summary of this revision.
estan edited the summary of this revision.
estan edited the summary of this revision.
estan updated this revision to Diff 398165.
estan added a comment.
estan added reviewers: aaron.ballman, alexfh, JonasToth, george.burgess.iv.
estan published this revision for review.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

Format code with git-clang-format


The cppcoreguidelines-pro-bounds-array-to-pointer-decay check currently accepts

  const char *b = i ? "foo" : "foobar";

but not

  const char *a = i ? "foo" : "bar";

This is because the AST is slightly different in the latter case (see 
https://godbolt.org/z/MkHVvs).

This fixes up the inconsistency by making it accept the latter form as well.

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D116814

Files:
  
clang-tools-extra/clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp


Index: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
===
--- 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
+++ 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
@@ -49,3 +49,14 @@
   void *a[2];
   f2(static_cast(a)); // OK, explicit cast
 }
+
+void issue31155(int i) {
+  const char *a = i ? "foo" : "bar";// OK, decay string literal to pointer
+  const char *b = i ? "foo" : "foobar"; // OK, decay string literal to pointer
+
+  char arr[1];
+  const char *c = i ? arr : "bar";
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: do not implicitly decay an 
array into a pointer
+  const char *d = i ? "foo" : arr;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: do not implicitly decay an 
array into a pointer
+}
Index: 
clang-tools-extra/clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
===
--- 
clang-tools-extra/clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
+++ 
clang-tools-extra/clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
@@ -54,13 +54,17 @@
   // 2) inside a range-for over an array
   // 3) if it converts a string literal to a pointer
   Finder->addMatcher(
-  traverse(TK_AsIs,
-   implicitCastExpr(
-   unless(hasParent(arraySubscriptExpr())),
-   unless(hasParentIgnoringImpCasts(explicitCastExpr())),
-   unless(isInsideOfRangeBeginEndStmt()),
-   
unless(hasSourceExpression(ignoringParens(stringLiteral()
-   .bind("cast")),
+  traverse(
+  TK_AsIs,
+  implicitCastExpr(
+  unless(hasParent(arraySubscriptExpr())),
+  unless(hasParentIgnoringImpCasts(explicitCastExpr())),
+  unless(isInsideOfRangeBeginEndStmt()),
+  unless(hasSourceExpression(ignoringParens(stringLiteral(,
+  unless(hasSourceExpression(ignoringParens(conditionalOperator(
+  allOf(hasTrueExpression(stringLiteral()),
+hasFalseExpression(stringLiteral(
+  .bind("cast")),
   this);
 }
 


Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
@@ -49,3 +49,14 @@
   void *a[2];
   f2(static_cast(a)); // OK, explicit cast
 }
+
+void issue31155(int i) {
+  const char *a = i ? "foo" : "bar";// OK, decay string literal to pointer
+  const char *b = i ? "foo" : "foobar"; // OK, decay string literal to pointer
+
+  char arr[1];
+  const char *c = i ? arr : "bar";
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: do not implicitly decay an array into a pointer
+  const char *d = i ? "foo" : arr;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: do not implicitly decay an array into a pointer
+}
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
@@ -54,13 +54,17 @@
   // 2) inside a range-for over an array
   // 3) if it converts a string literal to a

[PATCH] D88833: [clang-tidy] Do not warn on pointer decays in system macros

[Elvis Stansvik via Phabricator via cfe-commits]

estan commandeered this revision.
estan added a reviewer: fiesh.
estan added a comment.

I think we can close this one now that https://reviews.llvm.org/D116378 has 
landed though, since this revision was originally only about warnings in system 
macros case which is now solved (?)

I'll commandeer and close, but feel free to re-open if that's the wrong move 
here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88833

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

[PATCH] D116814: Accept string literal decay in conditional operator

[Elvis Stansvik via Phabricator via cfe-commits]

estan updated this revision to Diff 398177.
estan added a comment.

Add entry in clang-tools-extra/docs/ReleaseNotes.rst


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116814

Files:
  
clang-tools-extra/clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp


Index: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
===
--- 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
+++ 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
@@ -49,3 +49,14 @@
   void *a[2];
   f2(static_cast(a)); // OK, explicit cast
 }
+
+void issue31155(int i) {
+  const char *a = i ? "foo" : "bar";// OK, decay string literal to pointer
+  const char *b = i ? "foo" : "foobar"; // OK, decay string literal to pointer
+
+  char arr[1];
+  const char *c = i ? arr : "bar";
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: do not implicitly decay an 
array into a pointer
+  const char *d = i ? "foo" : arr;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: do not implicitly decay an 
array into a pointer
+}
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -67,6 +67,10 @@
 Improvements to clang-tidy
 --
 
+- Make the `cppcoreguidelines-pro-bounds-array-to-pointer-decay` check accept
+  string literal to pointer decay in conditional operator even if operands are
+  of the same length.
+
 - Ignore warnings from macros defined in system headers, if not using the
   `-system-headers` flag.
 
Index: 
clang-tools-extra/clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
===
--- 
clang-tools-extra/clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
+++ 
clang-tools-extra/clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
@@ -54,13 +54,17 @@
   // 2) inside a range-for over an array
   // 3) if it converts a string literal to a pointer
   Finder->addMatcher(
-  traverse(TK_AsIs,
-   implicitCastExpr(
-   unless(hasParent(arraySubscriptExpr())),
-   unless(hasParentIgnoringImpCasts(explicitCastExpr())),
-   unless(isInsideOfRangeBeginEndStmt()),
-   
unless(hasSourceExpression(ignoringParens(stringLiteral()
-   .bind("cast")),
+  traverse(
+  TK_AsIs,
+  implicitCastExpr(
+  unless(hasParent(arraySubscriptExpr())),
+  unless(hasParentIgnoringImpCasts(explicitCastExpr())),
+  unless(isInsideOfRangeBeginEndStmt()),
+  unless(hasSourceExpression(ignoringParens(stringLiteral(,
+  unless(hasSourceExpression(ignoringParens(conditionalOperator(
+  allOf(hasTrueExpression(stringLiteral()),
+hasFalseExpression(stringLiteral(
+  .bind("cast")),
   this);
 }
 


Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
@@ -49,3 +49,14 @@
   void *a[2];
   f2(static_cast(a)); // OK, explicit cast
 }
+
+void issue31155(int i) {
+  const char *a = i ? "foo" : "bar";// OK, decay string literal to pointer
+  const char *b = i ? "foo" : "foobar"; // OK, decay string literal to pointer
+
+  char arr[1];
+  const char *c = i ? arr : "bar";
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: do not implicitly decay an array into a pointer
+  const char *d = i ? "foo" : arr;
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: do not implicitly decay an array into a pointer
+}
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -67,6 +67,10 @@
 Improvements to clang-tidy
 --
 
+- Make the `cppcoreguidelines-pro-bounds-array-to-pointer-decay` check accept
+  string literal to pointer decay in conditional operator even if operands are
+  of the same length.
+
 - Ignore warnings from macros defined in system headers, if not using the
   `-system-headers` flag.
 
Index: clang-tools-extra/clang-tidy/cppcoreguideline

[PATCH] D116814: [clang-tidy] Accept string literal decay in conditional operator

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

Thanks @aaron.ballman. I don't have commit/push rights, so someone please 
commit for me when you got the time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116814

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

[PATCH] D116814: [clang-tidy] Accept string literal decay in conditional operator

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

Ah right, `Elvis Stansvik `


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116814

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

[PATCH] D116814: [clang-tidy] Accept string literal decay in conditional operator

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

👍


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116814

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

[PATCH] D116814: [clang-tidy] Accept string literal decay in conditional operator

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

BTW how are backports to release branches made in LLVM? (sorry if it's in the 
docs somewhere!)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116814

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

[PATCH] D116814: [clang-tidy] Accept string literal decay in conditional operator

[Elvis Stansvik via Phabricator via cfe-commits]

estan added a comment.

Ah thanks. Yea no worries.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116814

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