These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
Recent changes to add _BitInt support have caused our internal random
testing to fail. This change just avoids a readability magic numbers
check for now if a _BitInt. The crash seen (edited for clarity) is shown
below.
<src-root>/llvm/include/llvm/ADT/APInt.h:1488:
uint64_t llvm::APInt::getZExtValue() const: Assertion `getActiveBits()
<= 64 && "Too many bits for uint64_t"' failed.
...
#9 <address> llvm::APInt::getZExtValue() const
<src-root>/llvm/include/llvm/ADT/APInt.h:1488:5
clang::IntegerLiteral const*) const
<src-root>/clang-tools-extra/clang-tidy/readability/MagicNumbersCheck.cpp:198:47
<clang::IntegerLiteral>(clang::ast_matchers::MatchFinder::MatchResult
const&, char const*)
<src-root>/clang-tools-extra/clang-tidy/readability/MagicNumbersCheck.h:67:5
clang::ast_matchers::MatchFinder::MatchResult const&)
<src-root>/clang-tools-extra/clang-tidy/readability/MagicNumbersCheck.cpp:152:35
...
Reviewed By: donat.nagy
Some user-defined literals operate on implementation-defined types, like
"unsigned long long" and "long double", which are not well supported by
this check. Currently, the check gives warnings when using UDLs, without
giving possiblity to the user to whitelist common UDLs. A good compromise
until a proper fix is found (if any) is to allow the user to disable
warnings on UDLs.
Partially fixes#61656
Differential Revision: https://reviews.llvm.org/D146913
This commit introduces an option to the readability-magic-values checker.
The option defaults to false so that the behavior of the checker doesn't change unless specifically enabled.
These commits are supposed to fix https://github.com/llvm/llvm-project/issues/61259
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D145778
There's many instances in clang tidy checks where owning strings are used when we already have a stable string from the options, so using a StringRef makes much more sense.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D124341
Update clang-tools-extra, clang/tools, clang/unittests to migrate from
`SourceManager::getBuffer`, which returns an always dereferenceable
`MemoryBuffer*`, to `getBufferOrNone` or `getBufferOrFake`, both of
which return a `MemoryBufferRef`, depending on whether the call site was
checking for validity of the buffer. No functionality change intended.
Differential Revision: https://reviews.llvm.org/D89416
Just adds the storeOptions for Checks that weren't already storing their options.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D82223
`APFLoat::convertFromString` returns `Expected` result, which must be
"checked" if the LLVM_ENABLE_ABI_BREAKING_CHECKS preprocessor flag is
set.
To mark an `Expected` result as "checked" we must consume the `Error`
within.
In many cases, we are only interested in knowing if an error occured,
without the need to examine the error info. This is achieved, easily,
with the `errorToBool()` API.
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
