carlosgalvezp wrote:
We probably should have proper guidelines for aliases. IMO, there should only
be a "base -> coding guideline" kind of alias relationship, not the other way
around. Coding guidelines should "cherry-pick" (and possibly
configure/harden/make more strict) base checks. So in th
@@ -0,0 +1,8 @@
+// RUN: %check_clang_tidy -std=c++17 -expect-clang-tidy-error %s
performance-noexcept-move-constructor %t
carlosgalvezp wrote:
Does this need to be a separate file? Can't we just have it in an existing
test, inside `namespace PRX`?
https
carlosgalvezp wrote:
LGTM, had a small comment. Not sure it's worth mentioning this in the releases
notes, it's just a crash fix. But it doesn't hurt I guess.
https://github.com/llvm/llvm-project/pull/66810
___
cfe-commits mailing list
cfe-commits@lis
https://github.com/carlosgalvezp approved this pull request.
https://github.com/llvm/llvm-project/pull/118459
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
You have duplicated `readability` when referring to the document:
```
- 'clang-tidy/checks/readability/readability-use-span-first-last'
+ 'clang-tidy/checks/readability/use-span-first-last'
```
You can build them with: `ninja docs-clang-tools-html`, with following CMake
co
https://github.com/carlosgalvezp approved this pull request.
https://github.com/llvm/llvm-project/pull/118820
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,173 @@
+//===--- UseIntegerSignComparisonCheck.cpp - clang-tidy
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,47 @@
+//===--- UseIntegerSignComparisonCheck.h - clang-tidy ---*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
@@ -0,0 +1,36 @@
+.. title:: clang-tidy - modernize-use-integer-sign-comparison
+
+modernize-use-integer-sign-comparison
+=
+
+Replace comparisons between signed and unsigned integers with their safe
+C++20 ``std::cmp_*`` alternative, if availab
@@ -0,0 +1,47 @@
+//===--- UseIntegerSignComparisonCheck.h - clang-tidy ---*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
carlosgalvezp wrote:
Sorry for the late review, but isn't this already covered by `-Wall` with GCC?
At least the example from the check documentation:
https://godbolt.org/z/es37ozqe9
```
warning: 'sprintf' argument 3 overlaps destination object 'buf'
```
If this check is not redundant given t
carlosgalvezp wrote:
> Is this still worth adding here? I didn't see an equivalent in clang's -Wall.
Indeed Clang is missing this check in -Wall. For parity with GCC it probably
makes sense to add it to -Wall as well instead of being a clang-tidy check.
What do you think @AaronBallman ?
https
@@ -62,16 +62,29 @@ ClangTidyCheck::OptionsView::get(StringRef LocalName) const
{
return std::nullopt;
}
+static const llvm::StringSet<> DeprecatedGlobalOptions{
+"StrictMode",
+"IgnoreMacros",
+};
+
static ClangTidyOptions::OptionMap::const_iterator
findPriorityO
carlosgalvezp wrote:
Looks good in general. I wonder however how it will work for people who are
stuck in old clang-tidy files for whatever reason - this warning can be very
noisy if running clang-tidy in CI with lots of files. Do we need some CLI
option to allow users to silence the warnings?
carlosgalvezp wrote:
@HerrCai0907 I don't believe this comment has been addressed yet.
https://github.com/llvm/llvm-project/pull/120245
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
https://github.com/carlosgalvezp approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/120963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/120963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -62,16 +62,29 @@ ClangTidyCheck::OptionsView::get(StringRef LocalName) const
{
return std::nullopt;
}
+static const llvm::StringSet<> DeprecatedGlobalOptions{
+"StrictMode",
+"IgnoreMacros",
+};
+
static ClangTidyOptions::OptionMap::const_iterator
findPriorityO
https://github.com/carlosgalvezp commented:
I believe we should document this deprecation in the Release Notes.
https://github.com/llvm/llvm-project/pull/121057
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
carlosgalvezp wrote:
I have some mixed feelings as well, this could open the door for clang-tidy
becoming a tool for modernizing "any" 3rd-party library usage. It feels like
instead nlohmann/json should be the one responsible for providing a "migration
path" / tooling for these types of deprec
https://github.com/carlosgalvezp approved this pull request.
https://github.com/llvm/llvm-project/pull/119374
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -26,7 +26,7 @@ class InconsistentDeclarationParameterNameCheck : public
ClangTidyCheck {
ClangTidyContext *Context)
: ClangTidyCheck(Name, Context),
IgnoreMacros(Options.getLocalOrGlobal("IgnoreMacros", true)),
-
@@ -1,4 +1,4 @@
-// RUN: %check_clang_tidy -check-suffix=STRICT %s
cppcoreguidelines-pro-type-const-cast %t -- -config="{CheckOptions:
{StrictMode: true}}"
+// RUN: %check_clang_tidy -check-suffix=STRICT %s
cppcoreguidelines-pro-type-const-cast %t -- -config="{CheckOptions:
https://github.com/carlosgalvezp commented:
LGTM except the release notes, I think it would be more helpful to the users if
we listed the changes explicitly.
https://github.com/llvm/llvm-project/pull/120004
___
cfe-commits mailing list
cfe-commits@lis
@@ -115,6 +115,10 @@ Improvements to clang-tidy
- Improved :program:`run-clang-tidy.py` script. Fixed minor shutdown noise
happening on certain platforms when interrupting the script.
+- Removed :program:`clang-tidy`'s global options for most of checks. All
options
https://github.com/carlosgalvezp requested changes to this pull request.
LGTM! However I think we need to update:
- Release Notes. This is not quite a NFC change for users, since most of them
probably disable aliases, so some of them might be left out without this check
enabled.
- Alias table
https://github.com/carlosgalvezp approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/120004
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
It could also be that `getLocalOrGlobal` was added to keep backwards
compatibility and never break users, e.g for an option that used to be local
but has become global. But that doesn't mean that that's what we actually want
users to do.
https://github.com/llvm/llvm-proje
carlosgalvezp wrote:
They use getLocalOrGlobal probably by mistake, copy-pasting existing code. We
should document what we believe makes sense, and fix the implementation
accordingly. The current documentation says these options are check-specific,
so users should be using them per-check inste
carlosgalvezp wrote:
I think the confusion comes from calling these "Global Options". They are not
global, they "exist in multiple checks", however they can (and probably should)
change independently of each other. My understanding is that the scope of this
NFC patch is to DRY the documentatio
@@ -0,0 +1,21 @@
+==
+Global Options
+==
+
+Some options apply to multiple checks. This page lists all the available
+globally options.
+
+.. option:: IncludeStyle
+
+ A string specifying which include-style is used, `llvm` or `google`. Default
+ is `ll
@@ -0,0 +1,21 @@
+==
+Global Options
+==
+
+Some options apply to multiple checks. This page lists all the available
+globally options.
+
+.. option:: IncludeStyle
+
+ A string specifying which include-style is used, `llvm` or `google`. Default
+ is `ll
@@ -26,7 +26,8 @@ Options
.. option:: IgnoreMacros
carlosgalvezp wrote:
Personally I don't see much benefit in this change, it makes the documentation
harder to read as one has to go back and forth. I don't see the trouble with
this duplication, since it's
https://github.com/carlosgalvezp approved this pull request.
LGTM, thanks!
https://github.com/llvm/llvm-project/pull/119948
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
This change is not just a refactor, it leads to user-facing documentation
changes (which check alias which), so I think it should be mentioned in the
Release Notes. It doesn't cost anything to add it :)
https://github.com/llvm/llvm-project/pull/120245
@@ -553,6 +555,20 @@ static llvm::IntrusiveRefCntPtr
createBaseFS() {
int clangTidyMain(int argc, const char **argv) {
llvm::InitLLVM X(argc, argv);
+ SmallVector Args{argv, argv + argc};
+
+ llvm::BumpPtrAllocator Alloc;
carlosgalvezp wrote:
Can we add
https://github.com/carlosgalvezp requested changes to this pull request.
LGTM but I had a couple of comments
https://github.com/llvm/llvm-project/pull/120547
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
@@ -115,6 +115,8 @@ Improvements to clang-tidy
- Improved :program:`run-clang-tidy.py` script. Fixed minor shutdown noise
happening on certain platforms when interrupting the script.
+- Improved :program:`clang-tidy` by accepting parameters file in command line.
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/118459
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
=?utf-8?q?Félix-Antoine?= Constantin
Message-ID:
In-Reply-To:
carlosgalvezp wrote:
I too have the feeling that this feature is a responsibility of the build
system, not of clang-tidy. What do you think @AaronBallman ?
https://github.com/llvm/llvm-project/pull/111453
__
carlosgalvezp wrote:
> for this to make it easier to roll out?
Note that recently Clang introduced a mechanism for file-level suppression of
warnings, for easier rollout of warnings:
https://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-suppression-mappings
Would that serve
=?utf-8?q?Félix-Antoine?= Constantin
Message-ID:
In-Reply-To:
carlosgalvezp wrote:
The way we do it at our place is that we have 2 toolchains, one for GCC and one
for Clang, each with separate sets of flags. We assume that being able to
compile with Clang is a prerequisite to running clang-ti
@@ -13,79 +13,88 @@
using namespace clang::ast_matchers;
namespace clang::tidy::cppcoreguidelines {
-namespace {
-AST_MATCHER(FieldDecl, isMemberOfLambda) {
- return Node.getParent()->isLambda();
+static bool hasCopyConstructor(CXXRecordDecl const &Node) {
+ if (Node.needs
carlosgalvezp wrote:
> It is normal cases that source code and test code have different quality
> metrics.
+1. That's responsibility of the build system. "What is a test" is something
that can vary from project to project.
> is expected to be removed again
>From experience, removing flags i
carlosgalvezp wrote:
This check sounds a bit strange. Is this issue common in real-world projects,
do we have some data? It's the first time I've heard of it. Why would people
deviate from the standard signature for move constructors?
We could perhaps consider making this check a bit more gene
https://github.com/carlosgalvezp approved this pull request.
https://github.com/llvm/llvm-project/pull/120774
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
+1
https://github.com/llvm/llvm-project/pull/120245
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -29,6 +29,12 @@ static constexpr StringRef DefaultIncludeTypeRegex =
AST_MATCHER(VarDecl, isLocalVarDecl) { return Node.isLocalVarDecl(); }
AST_MATCHER(VarDecl, isReferenced) { return Node.isReferenced(); }
+AST_MATCHER_P(VarDecl, explicitMarkUnused, LangOptions, LangOpts)
carlosgalvezp wrote:
> that it is kept for future deprecations (and would therefore need to be
> general enough)
Yes, that was my thought, having a general-purpose mechanism for deprecation
warnings (a bit what I mentioned in the RFC).
Maybe something like `--no-deprecation-warnings` or
`--i
carlosgalvezp wrote:
> that it is kept for future deprecations (and would therefore need to be
> general enough)
Yes, that was my thought, some general-purpose mechanism for deprecation
warnings, for example `--disable-deprecation-warnings`,
`--no-deprecation-warnings`, etc.
The use case I h
https://github.com/carlosgalvezp updated
https://github.com/llvm/llvm-project/pull/132016
>From 6e1a50025c75cc5c3835046c66b720a75a6715f4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carlos=20G=C3=A1lvez?=
Date: Wed, 19 Mar 2025 12:28:49 +
Subject: [PATCH] [clang-tidy] Skip system macros in
rea
https://github.com/carlosgalvezp updated
https://github.com/llvm/llvm-project/pull/132016
>From 0d4f53cefc223a116b25f9106d37dc707c58ec0f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carlos=20G=C3=A1lvez?=
Date: Wed, 19 Mar 2025 12:28:49 +
Subject: [PATCH] [clang-tidy] Skip system macros in
rea
carlosgalvezp wrote:
Sorry for being late for the review. This is a major new feature of clang-tidy,
so I believe it would be good to have an RFC before looking at the detailed
implementation. What problem does it solve, why should clang-tidy solve it,
what the API towards the user should be,
carlosgalvezp wrote:
Hmm, it does not remove much
- Baseline: `Suppressed 196093 warnings (196093 in non-user code)`
- Trunk: `Suppressed 8050 warnings (8050 in non-user code).`
- Apparently there's a bug in the `isSystemHeader` function, since some core
compiler headers like `os_defines.h`
carlosgalvezp wrote:
Thanks for the info, sorry this created trouble for you!
An option to turn this behavior off should be easy to add. It's however
problematic if it lasts for more than one release because it's harder to
deprecate later.
It would be good to have a unit test of this case, w
carlosgalvezp wrote:
Btw I found [this
commit](https://github.com/llvm/llvm-project/commit/814e7974c64c977960c4913a117bf59af005865b)
which seemed to be intended at setting the basis for running clang-tidy on a
reduced AST, and where the `ParentMap` class was created.
@sam-mccall Perhaps you h
https://github.com/carlosgalvezp created
https://github.com/llvm/llvm-project/pull/132725
…atchFinder
This was introduced here with the purpose of speed up clang-tidy, making it not
process system headers:
https://github.com/llvm/llvm-project/commit/e4a8969e56572371201863594b3a549de2e23f32
H
carlosgalvezp wrote:
> reverting the previous solution
I thought about that, yes that might be cleaner. Will do!
https://github.com/llvm/llvm-project/pull/132725
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
https://github.com/carlosgalvezp created
https://github.com/llvm/llvm-project/pull/132743
…(#128150)"
This was too aggressive, and leads to problems for downstream users:
https://github.com/llvm/llvm-project/pull/128150#issuecomment-2739803409
Let's revert and reland it once we have addressed
@@ -94,8 +94,6 @@ Improvements to clang-tidy
- :program:`clang-tidy` no longer processes declarations from system headers
by default, greatly improving performance. This behavior is disabled if the
`SystemHeaders` option is enabled.
- Note: this may lead to false negatives
carlosgalvezp wrote:
Nit: specific in the commit message title that this is about
clang-tidy-diff.py. Otherwise it seems you are adding warnings as errors to
clang-tidy itself.
https://github.com/llvm/llvm-project/pull/128221
___
cfe-commits mailing
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/131594
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/carlosgalvezp created
https://github.com/llvm/llvm-project/pull/131594
None
>From b7c746e0cf7c0502b9b20bdeac2401742e02783e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carlos=20G=C3=A1lvez?=
Date: Mon, 17 Mar 2025 10:05:19 +
Subject: [PATCH] [clang][NFC] Fix typo 'initialize
carlosgalvezp wrote:
> We could, but also RenamerClangTidyVisitor could be improved to skip system
> code if not enabled.
I checked briefly and it does not seem to process system declarations already
now, it was just the macros that were missing.
https://github.com/llvm/llvm-project/pull/1320
@@ -0,0 +1,20 @@
+set(LLVM_LINK_COMPONENTS
+ support
+ )
+
+add_clang_library(clangTidyCustomModule STATIC
+ CustomTidyModule.cpp
+ QueryCheck.cpp
+
+ LINK_LIBS
+ clangTidy
+ clangTidyUtils
+
+ DEPENDS
+ ClangDriverOptions
+ )
+
+clang_target_link_libraries(clangTidyCust
carlosgalvezp wrote:
Maybe we do want to enable processing the macro if `SystemHeaders` is active?
https://github.com/llvm/llvm-project/pull/132016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
carlosgalvezp wrote:
If this is a CERT check, please add the corresponding aliases towards the CERT
module.
https://github.com/llvm/llvm-project/pull/130421
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
carlosgalvezp wrote:
> Hi, I tried to explain everything here:
Thanks, I missed that! For RFCs it's preferable to use
[Discourse](https://discourse.llvm.org/c/clang/clang-tidy/71), as there is a
lot less traffic and can more easily catch the eyes of relevant people. I did
not see much discuss
@@ -58,7 +58,7 @@ bool containsEscapedCharacters(const MatchFinder::MatchResult
&Result,
*Result.SourceManager, Result.Context->getLangOpts());
StringRef Text = Lexer::getSourceText(CharRange, *Result.SourceManager,
Result.Contex
https://github.com/carlosgalvezp approved this pull request.
LGTM, thanks for improving the docs!
https://github.com/llvm/llvm-project/pull/133525
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/c
https://github.com/carlosgalvezp commented:
LGTM, minor comment/question!
https://github.com/llvm/llvm-project/pull/133018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -89,6 +89,8 @@ void ConstCorrectnessCheck::registerMatchers(MatchFinder
*Finder) {
const auto ConstReference = hasType(references(isConstQualified()));
carlosgalvezp wrote:
On line 86 it appears the author intended to handle "const arrays" in the
"pointee
@@ -89,6 +89,8 @@ void ConstCorrectnessCheck::registerMatchers(MatchFinder
*Finder) {
const auto ConstReference = hasType(references(isConstQualified()));
carlosgalvezp wrote:
Alternatively we might want to correct/remove the comment
https://github.com/llvm/
carlosgalvezp wrote:
My main concern about this patch is putting the implementation into the config
file. We must be very careful with what we add to the config file, because it
must remain there unchanged forever. We must have an upfront design that we
believe will hold for the next N years w
https://github.com/carlosgalvezp approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/133018
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
> I found interesting was the fact that you could access the
> implementation-defined internal array field
Yes, this is required in order for `std::array` to be an aggregate type.
https://github.com/llvm/llvm-project/pull/134774
https://github.com/carlosgalvezp requested changes to this pull request.
We should fix `IgnoreSingleElementAggregates` instead.
https://github.com/llvm/llvm-project/pull/134774
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.
carlosgalvezp wrote:
Actually, it seems to me that `IgnoreSingleElementAggregates` should already be
handling this situation. If it doesn't, there's a bug there that should be
fixed, instead of patching it for `std::array`?
https://github.com/llvm/llvm-project/pull/134774
_
@@ -119,13 +119,18 @@
UseDesignatedInitializersCheck::UseDesignatedInitializersCheck(
void UseDesignatedInitializersCheck::registerMatchers(MatchFinder *Finder) {
const auto HasBaseWithFields =
hasAnyBase(hasType(cxxRecordDecl(has(fieldDecl();
+
+ // see #133715
+
@@ -119,13 +119,18 @@
UseDesignatedInitializersCheck::UseDesignatedInitializersCheck(
void UseDesignatedInitializersCheck::registerMatchers(MatchFinder *Finder) {
const auto HasBaseWithFields =
hasAnyBase(hasType(cxxRecordDecl(has(fieldDecl();
+
+ // see #133715
+
carlosgalvezp wrote:
Ok, I see, let's disable for ::std::array then, generalize in the future if we
come across a similar use case.
https://github.com/llvm/llvm-project/pull/134774
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
https://github.com/carlosgalvezp approved this pull request.
This should work, thanks! I still feel the whole framework needs a bit of
refactoring, the logic and data flow is a bit hidden and it's hard to spot
these dependencies that break because things are done in the wrong order.
https://gi
=?utf-8?q?Björn?= Svensson
Message-ID:
In-Reply-To:
@@ -50,183 +50,183 @@ namespace {
// with NULL argument and in this case the check is not applicable:
// `mblen, mbrlen, mbrtowc, mbtowc, wctomb, wctomb_s`.
// FIXME: The check can be improved to handle such cases.
-const l
=?utf-8?q?Bj=C3=B6rn?= Svensson
Message-ID:
In-Reply-To:
https://github.com/carlosgalvezp approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/135160
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
https://github.com/carlosgalvezp approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/133436
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/133436
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
Sure, thanks!
https://github.com/llvm/llvm-project/pull/133436
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/carlosgalvezp created
https://github.com/llvm/llvm-project/pull/133636
…-literal
Fixes #133618
>From 2baffdbd656723b15370d3dd3560f3bd62262664 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carlos=20G=C3=A1lvez?=
Date: Sun, 30 Mar 2025 12:24:32 +
Subject: [PATCH] [clang-tidy]
@@ -571,17 +560,30 @@ void
ClangTidyDiagnosticConsumer::checkFilters(SourceLocation Location,
}
StringRef FileName(File->getName());
- LastErrorRelatesToUserCode =
- LastErrorRelatesToUserCode || Sources.isInMainFile(Location) ||
- (HeaderFilter &&
- (Hea
carlosgalvezp wrote:
I believe it would be good to wait before the discussion settled in the issue
ticket. Personally I think this should be solved with a `NOLINT` suppression
instead of adding a new feature which just adds confusion.
https://github.com/llvm/llvm-project/pull/133639
__
https://github.com/carlosgalvezp updated
https://github.com/llvm/llvm-project/pull/133582
>From c2b1748bedf97f158a42ada308e22b1a4392ec9a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carlos=20G=C3=A1lvez?=
Date: Sat, 29 Mar 2025 11:55:02 +
Subject: [PATCH] [clang-tidy] Fix broken HeaderFilterReg
@@ -163,7 +163,11 @@ Options
Semicolon-separated list of containers without their template parameters
and some ``emplace``-like method of the container. Example:
``vector::emplace_back``. Those methods will be checked for improper use
and
-the check will report
@@ -163,7 +163,11 @@ Options
Semicolon-separated list of containers without their template parameters
and some ``emplace``-like method of the container. Example:
``vector::emplace_back``. Those methods will be checked for improper use
and
-the check will report
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/133525
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -105,7 +105,8 @@ char const *const StringizedMacroArgument = HAT(foo\\bar);
#define SUBST(lit_) lit_
carlosgalvezp wrote:
Good point, this doesn't work. It wants to create a replacement
`"R\"(foo\\bar\\baz\\bazz\\foo\"cd\")\""` which is non sense.
Most li
carlosgalvezp wrote:
This approach does not scale for macros, it should rather be implemented in a
`PPCallback` instead.
https://github.com/llvm/llvm-project/pull/133636
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/133636
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
carlosgalvezp wrote:
I've rebased on latest main now and intend to land it as soon as the CI checks
pass. Let me know if I should do any last-minute changes before that! Thank you
all for the review :)
https://github.com/llvm/llvm-project/pull/128150
__
https://github.com/carlosgalvezp updated
https://github.com/llvm/llvm-project/pull/128150
>From a4f57f491efd075c4788e31e3c52a090a6960a64 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Carlos=20G=C3=A1lvez?=
Date: Thu, 20 Feb 2025 12:37:15 +
Subject: [PATCH] [clang-tidy] Avoid processing declarati
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/128150
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
301 - 400 of 542 matches
Mail list logo
