Author: Mike Crowe
Date: 2023-03-05T17:16:20Z
New Revision: ae25e2f19decb94198301f0726ee613f945cc405
URL:
https://github.com/llvm/llvm-project/commit/ae25e2f19decb94198301f0726ee613f945cc405
DIFF:
https://github.com/llvm/llvm-project/commit/ae25e2f19decb94198301f0726ee613f945cc405.diff
LOG: [c
Author: Egor Suvorov
Date: 2023-03-05T18:22:10Z
New Revision: 9fda8322243168cbfcb78c4cf80afa838473a573
URL:
https://github.com/llvm/llvm-project/commit/9fda8322243168cbfcb78c4cf80afa838473a573
DIFF:
https://github.com/llvm/llvm-project/commit/9fda8322243168cbfcb78c4cf80afa838473a573.diff
LOG:
Author: Mike Crowe
Date: 2023-03-11T13:59:42Z
New Revision: efda335bf5be11b5ad4f94f3319d859563542553
URL:
https://github.com/llvm/llvm-project/commit/efda335bf5be11b5ad4f94f3319d859563542553
DIFF:
https://github.com/llvm/llvm-project/commit/efda335bf5be11b5ad4f94f3319d859563542553.diff
LOG: [c
Author: Carlos Galvez
Date: 2023-04-01T19:19:00Z
New Revision: 2469bd98a77242606426f8a5a8a797054c932bf0
URL:
https://github.com/llvm/llvm-project/commit/2469bd98a77242606426f8a5a8a797054c932bf0
DIFF:
https://github.com/llvm/llvm-project/commit/2469bd98a77242606426f8a5a8a797054c932bf0.diff
LOG:
Author: Carlos Galvez
Date: 2023-04-05T06:33:40Z
New Revision: 712dfec1781db8aa92782b98cac5517db548b7f9
URL:
https://github.com/llvm/llvm-project/commit/712dfec1781db8aa92782b98cac5517db548b7f9
DIFF:
https://github.com/llvm/llvm-project/commit/712dfec1781db8aa92782b98cac5517db548b7f9.diff
LOG:
Author: Carlos Galvez
Date: 2023-04-10T19:31:33Z
New Revision: 132f1d31fd66c30baf9773bf8f37b36a40fa7039
URL:
https://github.com/llvm/llvm-project/commit/132f1d31fd66c30baf9773bf8f37b36a40fa7039
DIFF:
https://github.com/llvm/llvm-project/commit/132f1d31fd66c30baf9773bf8f37b36a40fa7039.diff
LOG:
Author: Carlos Galvez
Date: 2023-04-15T10:10:04Z
New Revision: eedbe81b1c6dfbd85c2a46093e9e862335ad6516
URL:
https://github.com/llvm/llvm-project/commit/eedbe81b1c6dfbd85c2a46093e9e862335ad6516
DIFF:
https://github.com/llvm/llvm-project/commit/eedbe81b1c6dfbd85c2a46093e9e862335ad6516.diff
LOG:
Author: Carlos Galvez
Date: 2023-04-15T12:07:18Z
New Revision: fa3de2ed2964d18dd0b7457e77416fb4e688c8bd
URL:
https://github.com/llvm/llvm-project/commit/fa3de2ed2964d18dd0b7457e77416fb4e688c8bd
DIFF:
https://github.com/llvm/llvm-project/commit/fa3de2ed2964d18dd0b7457e77416fb4e688c8bd.diff
LOG:
Author: Carlos Galvez
Date: 2023-04-15T14:49:20Z
New Revision: d69c362dfdc09d9b866cbce007e6342c17af2b2a
URL:
https://github.com/llvm/llvm-project/commit/d69c362dfdc09d9b866cbce007e6342c17af2b2a
DIFF:
https://github.com/llvm/llvm-project/commit/d69c362dfdc09d9b866cbce007e6342c17af2b2a.diff
LOG:
Author: Nathan James
Date: 2023-04-15T15:07:44Z
New Revision: 4530c3bc4897f6633577de07b61ceb1bf7e79f50
URL:
https://github.com/llvm/llvm-project/commit/4530c3bc4897f6633577de07b61ceb1bf7e79f50
DIFF:
https://github.com/llvm/llvm-project/commit/4530c3bc4897f6633577de07b61ceb1bf7e79f50.diff
LOG:
Author: Carlos Galvez
Date: 2023-04-17T06:09:59Z
New Revision: b507bda4552347e00197032526c7ab4a80a853c2
URL:
https://github.com/llvm/llvm-project/commit/b507bda4552347e00197032526c7ab4a80a853c2
DIFF:
https://github.com/llvm/llvm-project/commit/b507bda4552347e00197032526c7ab4a80a853c2.diff
LOG:
Author: Carlos Galvez
Date: 2023-02-09T12:19:36Z
New Revision: 2706919f91977f3859ad625d4fb624fb04857e4f
URL:
https://github.com/llvm/llvm-project/commit/2706919f91977f3859ad625d4fb624fb04857e4f
DIFF:
https://github.com/llvm/llvm-project/commit/2706919f91977f3859ad625d4fb624fb04857e4f.diff
LOG:
Author: BigPeet
Date: 2023-02-10T18:52:56Z
New Revision: a543d840ee0ac53ef9df70c0e2a996e1a222064b
URL:
https://github.com/llvm/llvm-project/commit/a543d840ee0ac53ef9df70c0e2a996e1a222064b
DIFF:
https://github.com/llvm/llvm-project/commit/a543d840ee0ac53ef9df70c0e2a996e1a222064b.diff
LOG: Fix h
Author: Carlos Galvez
Date: 2023-02-15T10:38:36Z
New Revision: 45ddc157ca7c464ebbea627da0f682b1554e2390
URL:
https://github.com/llvm/llvm-project/commit/45ddc157ca7c464ebbea627da0f682b1554e2390
DIFF:
https://github.com/llvm/llvm-project/commit/45ddc157ca7c464ebbea627da0f682b1554e2390.diff
LOG:
Author: Carlos Galvez
Date: 2023-02-19T13:44:11Z
New Revision: 5b37cddff8e0140420ad776066529cf8f41d64d2
URL:
https://github.com/llvm/llvm-project/commit/5b37cddff8e0140420ad776066529cf8f41d64d2
DIFF:
https://github.com/llvm/llvm-project/commit/5b37cddff8e0140420ad776066529cf8f41d64d2.diff
LOG:
Author: Carlos Galvez
Date: 2023-02-19T13:58:31Z
New Revision: 14fee3d7d36927d3e8940cbcaab70fa4e99e2ec2
URL:
https://github.com/llvm/llvm-project/commit/14fee3d7d36927d3e8940cbcaab70fa4e99e2ec2
DIFF:
https://github.com/llvm/llvm-project/commit/14fee3d7d36927d3e8940cbcaab70fa4e99e2ec2.diff
LOG:
Author: Alexis Murzeau
Date: 2023-02-21T07:37:42Z
New Revision: dc43f7107e2916035b3503a10977182b03203046
URL:
https://github.com/llvm/llvm-project/commit/dc43f7107e2916035b3503a10977182b03203046
DIFF:
https://github.com/llvm/llvm-project/commit/dc43f7107e2916035b3503a10977182b03203046.diff
LOG
Author: Björn Svensson
Date: 2023-02-23T20:07:50Z
New Revision: 2928746ac3f1aabbecbe8da1525127443ebec2cf
URL:
https://github.com/llvm/llvm-project/commit/2928746ac3f1aabbecbe8da1525127443ebec2cf
DIFF:
https://github.com/llvm/llvm-project/commit/2928746ac3f1aabbecbe8da1525127443ebec2cf.diff
LOG
Author: Alexis Murzeau
Date: 2023-02-24T07:15:19Z
New Revision: 87447bedac341f023569f1b444f9b3b62bba5aa6
URL:
https://github.com/llvm/llvm-project/commit/87447bedac341f023569f1b444f9b3b62bba5aa6
DIFF:
https://github.com/llvm/llvm-project/commit/87447bedac341f023569f1b444f9b3b62bba5aa6.diff
LOG
Author: Carlos Galvez
Date: 2023-05-07T16:36:30Z
New Revision: 26f476286fbcb5cde51176abb2d3c6c0986bc410
URL:
https://github.com/llvm/llvm-project/commit/26f476286fbcb5cde51176abb2d3c6c0986bc410
DIFF:
https://github.com/llvm/llvm-project/commit/26f476286fbcb5cde51176abb2d3c6c0986bc410.diff
LOG:
Author: Carlos Galvez
Date: 2023-05-09T16:45:02Z
New Revision: 0d6d8a853a6ea29b5f461a475a8f8eb7e7ba18e2
URL:
https://github.com/llvm/llvm-project/commit/0d6d8a853a6ea29b5f461a475a8f8eb7e7ba18e2
DIFF:
https://github.com/llvm/llvm-project/commit/0d6d8a853a6ea29b5f461a475a8f8eb7e7ba18e2.diff
LOG:
Author: Carlos Galvez
Date: 2022-12-08T11:40:50Z
New Revision: 7fd8387917167d9cb4bab14a8548f0f78b0eaa79
URL:
https://github.com/llvm/llvm-project/commit/7fd8387917167d9cb4bab14a8548f0f78b0eaa79
DIFF:
https://github.com/llvm/llvm-project/commit/7fd8387917167d9cb4bab14a8548f0f78b0eaa79.diff
LOG:
Author: Carlos Galvez
Date: 2022-12-12T14:05:19Z
New Revision: d3c3de63ce8416ab2dee7f784e54b00a2aa8ed85
URL:
https://github.com/llvm/llvm-project/commit/d3c3de63ce8416ab2dee7f784e54b00a2aa8ed85
DIFF:
https://github.com/llvm/llvm-project/commit/d3c3de63ce8416ab2dee7f784e54b00a2aa8ed85.diff
LOG:
Author: Carlos Galvez
Date: 2022-12-12T14:49:09Z
New Revision: dabda23f1991f7c4e5a840ee6cf1290e18fa2e88
URL:
https://github.com/llvm/llvm-project/commit/dabda23f1991f7c4e5a840ee6cf1290e18fa2e88
DIFF:
https://github.com/llvm/llvm-project/commit/dabda23f1991f7c4e5a840ee6cf1290e18fa2e88.diff
LOG:
Author: Carlos Galvez
Date: 2022-12-12T15:26:14Z
New Revision: 35d9f873e3f21846de1b8f07271feedbbe8518ed
URL:
https://github.com/llvm/llvm-project/commit/35d9f873e3f21846de1b8f07271feedbbe8518ed
DIFF:
https://github.com/llvm/llvm-project/commit/35d9f873e3f21846de1b8f07271feedbbe8518ed.diff
LOG:
Author: Carlos Galvez
Date: 2022-12-16T06:54:16Z
New Revision: 66bf54abb54e6eafb08fcece87cf5d9d32fedcd3
URL:
https://github.com/llvm/llvm-project/commit/66bf54abb54e6eafb08fcece87cf5d9d32fedcd3
DIFF:
https://github.com/llvm/llvm-project/commit/66bf54abb54e6eafb08fcece87cf5d9d32fedcd3.diff
LOG:
carlosgalvezp wrote:
This problem seems like it should be handled globally, not in a single specific
check. IIUC any check that reads options from the .cñsng-tidy file is affected.
What build system are you using, bazel? We use it and don't have any problems.
If your build system creates a san
carlosgalvezp wrote:
> Why "ignore" instead of "filter"?
Why can't we make "filter" use a full regex that supports negative expressions
instead?
https://github.com/llvm/llvm-project/pull/82416
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -97,6 +97,9 @@ The improvements are...
Improvements to clang-tidy
--
+- Improved :program:`run-clang-tidy.py` script. Added argument `-source-filter`
+ to filter out source files from the compilation database.
carlosgalvezp wrote:
https://github.com/carlosgalvezp created
https://github.com/llvm/llvm-project/pull/97969
Since in C++ they already have implicit internal linkage.
Fixes #97947
>From 07bd62f97d203bbdb865cd4b1e14cef3ead70c80 Mon Sep 17 00:00:00 2001
From: Carlos Galvez
Date: Sun, 7 Jul 2024 21:11:54 +0200
Subj
carlosgalvezp wrote:
Thanks! Btw is the check intended to be used in C code as well? (I do not see C
tests for it). If not, then i can move the logic to the matcher to keep it a
bit cleaner, and restrict the check to C++ code.
The warning text mentions anonymous namespaces which would not be
https://github.com/carlosgalvezp updated
https://github.com/llvm/llvm-project/pull/97969
>From a1fec907b5d3920d5dda8761b6e173e153b7f281 Mon Sep 17 00:00:00 2001
From: Carlos Galvez
Date: Sun, 7 Jul 2024 21:11:54 +0200
Subject: [PATCH] [clang-tidy] Do not warn on const variables in
misc-use-int
https://github.com/carlosgalvezp updated
https://github.com/llvm/llvm-project/pull/97969
>From 07bd62f97d203bbdb865cd4b1e14cef3ead70c80 Mon Sep 17 00:00:00 2001
From: Carlos Galvez
Date: Sun, 7 Jul 2024 21:11:54 +0200
Subject: [PATCH] [clang-tidy] Do not warn on const variables in
misc-use-int
carlosgalvezp wrote:
> When check were created with C++ in mind, it could work also for C. Would be
> good to support both, or mention in documentation that check is limited to
> C++, and maybe if there will be requests in future, it could be expanded to C.
Thanks for the input, in that case I
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/106784
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/carlosgalvezp approved this pull request.
LGTM, thanks for the quick fix!
https://github.com/llvm/llvm-project/pull/107412
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co
https://github.com/carlosgalvezp created
https://github.com/llvm/llvm-project/pull/108083
To detect unsafe use of bit_cast that should be reinterpret_cast instead.
Otherwise, bit_cast bypasses all checks done by compilers and linters.
Fixes #106987
>From 6916d5ecdc327b2771fbbca226095bd99d394d
carlosgalvezp wrote:
Perhaps we can start with only pointer-to-pointer, yes. The original intention
was to forbid that:
https://www.open-std.org/jtc1/sc22/WG21/docs/papers/2016/p0476r0.html#det
```cpp
https://github.com/llvm/llvm-project/pull/108083
__
carlosgalvezp wrote:
Perhaps we can start with pointer-to-pointer only, yes. Pointer-int conversions
are still implementation-defined, but I guess it's less of a problem than UB.
The original paper only checked that both inputs are not pointers:
```cpp
!(is_pointer_v &&
is_pointer_v) &&
https://github.com/carlosgalvezp updated
https://github.com/llvm/llvm-project/pull/108083
>From c4d85703ee004522746df940f7b08cabaa0f4eca Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carlos=20G=C3=A1lvez?=
Date: Tue, 10 Sep 2024 13:46:51 +
Subject: [PATCH] [clang-tidy] Create bugprone-bit-cast-p
carlosgalvezp wrote:
Thanks for the review and the info @thesamesam ! AFAICS the MPL issue is fixed
on trunk, targeting release 1.86.
About Pycuda, it's also stemming from MPL according to the build logs.
So it seems to me the solution to these projects is too "just" bump to the
newer MPL ver
https://github.com/carlosgalvezp requested changes to this pull request.
There might be people who don't want uppercase suffix, so this will cause
problems to them. This should be put into a configuration option instead.
https://github.com/llvm/llvm-project/pull/102831
_
carlosgalvezp wrote:
> Is it possible to check whether is other check enable?
It might be technically possible, but it's undesirable as it makes the whole
infrastructure more complex and doubles the amount of testing. Checks should be
independent of each other.
https://github.com/llvm/llvm-pr
carlosgalvezp wrote:
Since boost/mpl is at the core of issues and many projects depend directly or
transitively on it, I think it might be good to wait until version 1.86 is
released, so people can bump to a release version instead of trunk.
It should be around the corner, [AFAICS](https://ww
carlosgalvezp wrote:
> How soon after 1.86 landing do you plan to submit this?
I was thinking as soon as it's released, I don't see a reason for waiting any
longer. The sooner we merge the sooner we can collect feedback and re-adjust if
needed. But of course it's up to the Clang owners to deci
carlosgalvezp wrote:
A bit of nitpick, but would it make sense to have some consistency with
`readability-identifier-naming`?
Instead of `UseUpperCase`, I'm thinking of:
`LiteralSuffixCase: LowerCase/UpperCase`
Like I said, not a big deal, I'm just posting as suggestion in case you like it
b
carlosgalvezp wrote:
Boost/MPL 1.86.0 is now released!
https://github.com/boostorg/mpl/releases/tag/boost-1.86.0
Thus I'm merging this patch, thanks for the reviews! I will keep an eye in case
there's need for a revert.
https://github.com/llvm/llvm-project/pull/102364
___
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/102364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
> the user may not have the ability to change the definition of the macro to be
> able to appease the check
My understanding of this PR is that the user would only need to change what
they pass into the macro, not the macro itself, or? E.g.
```cpp
-MY_MACRO(foo)
+MY_MACRO
carlosgalvezp wrote:
Nice! Should we add this example as a test case?
https://github.com/llvm/llvm-project/pull/87792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
Great! Nothing else from my side
https://github.com/llvm/llvm-project/pull/87792
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -15,3 +15,5 @@ std::string HelloString;
// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: no header providing "std::string"
is directly included [misc-include-cleaner]
int FooBarResult = foobar();
// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: no header providing "foobar" is
direc
carlosgalvezp wrote:
To be clear and reiterate my previous comment: this check should NOT require
users to use at(). That behavior should be opt-in. It should only warn about
using operator[]. It's up to the users to figure out what the best replacement
is.
https://github.com/llvm/llvm-projec
carlosgalvezp wrote:
> I don't think it is a good solution.
Can you elaborate?
As I wrote above, the C++ Core Guidelines do not require using `at()`.
Therefore the check would be doing something different than what the guidelines
require. The reason they don't require it is that there's multi
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?=
Message-ID:
In-Reply-To:
carlosgalvezp wrote:
> Rename the analysis from AvoidBoundsErrorsCheck to
> PreferAtOverSubscriptOperatorCheck as r
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?=
Message-ID:
In-Reply-To:
carlosgalvezp wrote:
The check certainly doesn't need to fully implement the guideline right now, it
can be done in
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?=
Message-ID:
In-Reply-To:
carlosgalvezp wrote:
>
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?=
Message-ID:
In-Reply-
Paul =?utf-8?q?Heidekr=C3=BCger?= ,
Paul =?utf-8?q?Heidekr=C3=BCger?= ,
Paul =?utf-8?q?Heidekr=C3=BCger?= ,
Paul =?utf-8?q?Heidekr=C3=BCger?= ,
Paul =?utf-8?q?Heidekr=C3=BCger?= ,
Paul =?utf-8?q?Heidekr=C3=BCger?= ,
Paul =?utf-8?q?Heidekr=C3=BCger?= ,
Paul =?utf-8?q?Heidekr=C3=BCger?= ,
Paul =?utf-
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heide
carlosgalvezp wrote:
I have a bit the feeling that users should use NOLINT* here instead of having a
global option that is not seen in the code. Anonymous namespaces do not solve
many of the remaining issues. A NOLINT in the code can grab the attention of a
future developer and prompt a refact
carlosgalvezp wrote:
This is not allowed by the relevant rule of the C++ Core Guidelines. We must be
careful to implement exactly only what the rules say, nothing more. You can on
course open a ticket to the C++ Core Guidelines asking them to change the rule
text.
IMHO this case seems too nic
carlosgalvezp wrote:
Good check idea! A couple of comments:
- This is not really a "modernize"check. Both styles are equally valid and it's
a matter of taste. Modernize is typically for checks that bump from one
standard to a newer one.
- Instead I think this check fits better in "readabili
https://github.com/carlosgalvezp requested changes to this pull request.
Good check idea! A couple of comments:
- This is not really a "modernize"check. Both styles are equally valid and it's
a matter of taste. Modernize is typically for checks that bump from one
standard to a newer one.
- In
carlosgalvezp wrote:
Please note: the guidelines do not require one to replace [] with at(), that's
just one of the possible solutions. Actually at() is banned in many codebases
where exceptions are banned.
It would be good to make this fix-it opt-in, configurable via option, so the
check on
carlosgalvezp wrote:
@Da-Viper I believe there's some merge conflicts to fix before being able to
merge :)
https://github.com/llvm/llvm-project/pull/104882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/104882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
Thanks, merged! I've edited the commit message a bit to better reflect the
content of the patch, as well as mark a related issue as fixed.
https://github.com/llvm/llvm-project/pull/104882
___
cfe-commits mailing list
cfe-commits@l
https://github.com/carlosgalvezp created
https://github.com/llvm/llvm-project/pull/106784
…ugh-void
reinterpret_cast is the equivalent construct, and more clearly expresses intent.
>From d3f0a650d7e3ad5bc8134e4c1fbb84ccb82d5105 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carlos=20G=C3=A1lvez?=
D
https://github.com/carlosgalvezp created
https://github.com/llvm/llvm-project/pull/106922
…t to allow casts to byte types
These casts are safe according to the Standard, so add an option to allow them
and not emit a warning. This helps silencing some noise and focusing on the
unsafe casts.
>
carlosgalvezp wrote:
I suppose it doesn't hurt to mention it. Don't tests need to be updated too?
https://github.com/llvm/llvm-project/pull/106862
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
carlosgalvezp wrote:
On another thought, the use case is quite niche and it's probably best for
people to create their own `safe_reinterpret_cast` wrapper. Let's keep the
check simple.
https://github.com/llvm/llvm-project/pull/106922
___
cfe-commits
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/106922
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/carlosgalvezp updated
https://github.com/llvm/llvm-project/pull/106784
>From d88a21655116da6ce8fed558ed9d7ea1ceb5e862 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carlos=20G=C3=A1lvez?=
Date: Fri, 30 Aug 2024 19:17:16 +
Subject: [PATCH] [clang-tidy] Suggest using reinterpret_
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/97969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
- I'm not sure this is so much a readability check, I'd put it in `misc`. The
main problem that it solves is avoiding ODR violations. I'd call it
`misc-prefer-internal-linkage`.
- The auto-fix should be configurable to choose `static` or anonymous namespace.
https://git
carlosgalvezp wrote:
> Should I implement auto-fix for this check?
As a first step we can have it without auto-fix and add that as a second step
once we figure out a good way to do it.
https://github.com/llvm/llvm-project/pull/90830
___
cfe-commits m
carlosgalvezp wrote:
Regarding the problem of {} initialization and std::vector, I believe we could
restrict this check to not warn on classes that have a constructor taking a
`std:: initializer_list`. I believe AUTOSAR has an exception for that.
https://github.com/llvm/llvm-project/pull/91124
carlosgalvezp wrote:
Consider also that this check should probably not apply to variables of type
`auto`, see AUTOSAR rule A8-5-3.
https://github.com/llvm/llvm-project/pull/91124
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.ll
carlosgalvezp wrote:
I'm not very happy about the name, there's no such thing as "virtual
arithmetic".
What about "bugprone-pointer-arithmetic-polymorphic-object"?
I rather have a long descriptive name than a short ambiguous name.
https://github.com/llvm/llvm-project/pull/91951
__
carlosgalvezp wrote:
Otherwise since this is a problem also on non-polymorphic objects, maybe
"bugprone-pointer-arithmetic-base-class"?
https://github.com/llvm/llvm-project/pull/91951
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lis
carlosgalvezp wrote:
I realize it's probably very hard (if not impossible) to detect whether a class
is a base class unless it has virtual functions.
That's why the corresponding AUTOSAR rule bans only non-final classes. But that
is a bit overkill and leads to some pain.
https://github.com
carlosgalvezp wrote:
A bit late for the review but would have been nice to name the test
"out-of-line" instead of "ool", so it's easier to understand what it's about.
https://github.com/llvm/llvm-project/pull/91954
___
cfe-commits mailing list
cfe-com
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heidekrüger?= ,
Paul =?utf-8?q?Heide
https://github.com/carlosgalvezp created
https://github.com/llvm/llvm-project/pull/102364
The warning has been active for a few releases now, first only in user code,
later in system headers, and finally as an error by default.
Therefore, we believe it is now time to transition into a hard err
https://github.com/carlosgalvezp updated
https://github.com/llvm/llvm-project/pull/102364
>From 88f1a873d6c6ef06ad9a1847d098d65845cf1469 Mon Sep 17 00:00:00 2001
From: Carlos Galvez
Date: Tue, 6 Aug 2024 22:50:10 +0200
Subject: [PATCH 1/2] [clang] Turn -Wenum-constexpr-conversion into a hard
e
@@ -49,6 +49,9 @@ C++ Specific Potentially Breaking Changes
few users and can be written as ``__is_same(__remove_cv(T),
decltype(nullptr))``,
which GCC supports as well.
+- The warning `-Wenum-constexpr-conversion` has been upgraded into a hard
+ compiler error that cann
carlosgalvezp wrote:
By the way, the latest revision of the GDB patch (improved after the first
round of review) can be found here:
https://sourceware.org/pipermail/gdb-patches/2024-June/210252.html
https://github.com/llvm/llvm-project/pull/102364
__
Author: Carlos Galvez
Date: 2022-01-23T15:52:42Z
New Revision: eb3f20e8fa4b76e0103f15623a2fc3b27fb03f85
URL:
https://github.com/llvm/llvm-project/commit/eb3f20e8fa4b76e0103f15623a2fc3b27fb03f85
DIFF:
https://github.com/llvm/llvm-project/commit/eb3f20e8fa4b76e0103f15623a2fc3b27fb03f85.diff
LOG:
Author: Carlos Galvez
Date: 2022-01-06T20:27:28Z
New Revision: 670de10f9deaa83f4d1db6e793c74cbfd18c65c1
URL:
https://github.com/llvm/llvm-project/commit/670de10f9deaa83f4d1db6e793c74cbfd18c65c1
DIFF:
https://github.com/llvm/llvm-project/commit/670de10f9deaa83f4d1db6e793c74cbfd18c65c1.diff
LOG:
Author: Carlos Galvez
Date: 2022-01-12T08:18:19Z
New Revision: c4db521cea32fcfb714d1a622e0efce69a564a28
URL:
https://github.com/llvm/llvm-project/commit/c4db521cea32fcfb714d1a622e0efce69a564a28
DIFF:
https://github.com/llvm/llvm-project/commit/c4db521cea32fcfb714d1a622e0efce69a564a28.diff
LOG:
Author: Carlos Galvez
Date: 2021-10-16T08:27:08Z
New Revision: f0711106dc6c14dcaf06437a0467043e983bf9dc
URL:
https://github.com/llvm/llvm-project/commit/f0711106dc6c14dcaf06437a0467043e983bf9dc
DIFF:
https://github.com/llvm/llvm-project/commit/f0711106dc6c14dcaf06437a0467043e983bf9dc.diff
LOG:
Author: Carlos Galvez
Date: 2021-10-19T16:30:51Z
New Revision: bf6b0d16747f6d1107de1a51d42ae3b0bf904537
URL:
https://github.com/llvm/llvm-project/commit/bf6b0d16747f6d1107de1a51d42ae3b0bf904537
DIFF:
https://github.com/llvm/llvm-project/commit/bf6b0d16747f6d1107de1a51d42ae3b0bf904537.diff
LOG:
Author: Carlos Galvez
Date: 2021-10-19T16:37:56Z
New Revision: 7812cb72a321c392a3b91b45b4780a0987818a36
URL:
https://github.com/llvm/llvm-project/commit/7812cb72a321c392a3b91b45b4780a0987818a36
DIFF:
https://github.com/llvm/llvm-project/commit/7812cb72a321c392a3b91b45b4780a0987818a36.diff
LOG:
carlosgalvezp wrote:
> An inconsistency is that readability-uppercase-literal-suffix only handles l
> and u by default whereas the check here also handles f
Then that check should be updated to handle the F suffix as well.
It doesn't make sense to have different style for different suffixes:
https://github.com/carlosgalvezp requested changes to this pull request.
We have explicitly said in the other PR that we do *not* want checks to depend
on each other. Checks must remain independent of each other.
https://github.com/llvm/llvm-project/pull/104694
_
https://github.com/carlosgalvezp edited
https://github.com/llvm/llvm-project/pull/104694
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/carlosgalvezp edited
https://github.com/llvm/llvm-project/pull/104694
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
No problem, thanks for the initiative! We should probably clarify this in the
developer documentation.
https://github.com/llvm/llvm-project/pull/104694
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
carlosgalvezp wrote:
> An inconsistency is that readability-uppercase-literal-suffix only handles l
> and u by default whereas the check here also handles f
Actually `readability-uppercase-literal-suffix` does handle `f` as well so I'm
not sure I understand this comment.
https://github.com/ll
101 - 200 of 542 matches
Mail list logo
