A recent change to LLVM removed LLVM_ATTRIBUTE_NORETURN in favor of plain C++11
[[noreturn]]. Since we require C++14 to build these days, just assume that
the [[noreturn]] attribute is available.
llvm::Regex does not support negative lookaround, so there was no way to do
negative assertions such as:
"@\"((?!.*/internal/).*)-inl.h\""
as part of mapping rules.
Switch to std::regex (which defaults to ECMAScript regex dialect) to allow these
constructs.
In the parent commit, I forgot to update the build so that include-what-you-use
links with all targets, which led to link failures for builds against LLVM build
trees (as opposed to the Debian packages).
While troubleshooting this, I found a patch by @Romain-Geissler-1A that I had
previously misunderstood/overlooked:
https://github.com/include-what-you-use/include-what-you-use/pull/854#issuecomment-732487734
Borrowing the link dependencies from that patch to complete my accidental
plagiarism fixes the build again.
It used to be the case that the MS inline assembly parser in Clang crashed if an
X86 target was not registered and initialized.
The error handling there has been improved, so now Clang complains and says it
needs X86 target support to continue, and raises an error.
That's good news for IWYU, as the majority of code we analyze has no MS inline
assembly (fingers crossed!). So instead of requiring an X86 target to be
included, initialize _all_ registered LLVM targets and assume that X86 is
available in any configuration intended for use with MS inline assembly.
This makes it possible to build a fully non-X86 toolchain including IWYU.
We already have a rule that if a decl is used entirely inside a macro, and it's
forward-declared in the macro file, the use is attributed to the expansion
location. This, however, did not cover template specializations, as described in
issue 847.
So now we treat a primary function template declaration in the macro file as a
regular forward-declaration, which means that function template specializations
used in macros will be attributed to the expansion location iff the primary
template has a declaration in the macro file.
CTAD is a C++17 feature that allows template arguments to be deduced from
constructor expressions. For example:
A a(10, 20);
is shorthand for:
A<int, int> a(10, 20);
This should fix issue #826.
If a library defines intptr_t in <unistd.h> that's a bug.
It shall only be defined in <stdint.h> and <inttypes.h>.
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
If some library defines int8_t in <sys/types.h>, that's a bug.
The standard only defines it in <stdint.h> and <inttypes.h>.
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Slightly different /EH flags are now provided by LLVM's CMake system,
and MSVC warns that they're inconsistent.
They're the same in spirit, so let LLVM decide.
Kim Gräsman