Previously, any macro that didn't look like a varargs macro
or a function style macro was reported with a warning that
it should be replaced with a constexpr const declaration.
This is only reasonable when the macro body contains constants
and not expansions like ",", "[[noreturn]]", "__declspec(xxx)",
etc.
So instead of always issuing a warning about every macro that
doesn't look like a varargs or function style macro, examine the
tokens in the macro and only warn about the macro if it contains
only comment and constant tokens.
Differential Revision: https://reviews.llvm.org/D116386Fixes#39945
Current check compiles the regex on every attempt at matching. The check also populates and enables a regex value by default so the default behaviour results in regex re-compilation for every macro - if the check is enabled. If people used this check there's a reasonable chance they would have relatively complex regexes in use.
This is a quick and simple fix to store and use the compiled regex.
Reviewed By: njames93
Differential Revision: https://reviews.llvm.org/D91908
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368944
Before the patch calling clang-tidy with -header-filter=.* -system-headers would
result in a few hundred useless warnings:
warning: macro '_GNU_SOURCE' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '_LP64' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_ACQUIRE' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_ACQ_REL' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_CONSUME' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_RELAXED' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_RELEASE' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_SEQ_CST' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__BIGGEST_ALIGNMENT__' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
... and so on
llvm-svn: 358621
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
The macro may not have location (or more generally, the location may not exist),
e.g. if it originates from compiler's command-line.
The check complains on all the macros, even those without the location info.
Which means, it only says it does not like it. What is 'it'? I have no idea.
If we don't print the name, then there is no way to deal with that situation.
And in general, not printing name here forces the user to try to understand,
given, the macro definition location, what is the macro name?
This isn't fun.
Also, ignores-by-default the macros originating from command-line,
with an option to not ignore those.
I suspect some more issues may crop up later.
Reviewers: JonasToth, aaron.ballman, hokein, xazax.hun, alexfh
Reviewed By: JonasToth, aaron.ballman
Subscribers: nemanjai, kbarton, rnkovacs, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D53817
llvm-svn: 345610
Richard