In December 2018, the header clang/Frontend/FrontendDiagnostic.h moved
to clang/Basic/DiagnosticFrontend.h. The old header was left around for
compatibility.
Use the new one instead.
Sorry I'm late.
As a fix for issue #247 we added a block of hard-coded paths to the
include search path, which would find libc++ from the MacOS SDK.
While the MacOS SDK is usually present where IWYU is run, on developer
machines, there may be any number of other sysroots providing libc++
that users would prefer to use.
The Nix tool is one such player, where builds are isolated and all
dependencies are gathered in a single root for reproducibility.
Recent experiments with Clang on different Mac systems show that:
* if the MacOS SDK is present, IWYU picks it up automatically via the
Clang driver
* if the MacOS SDK is not present, no include paths are conjured out of
thin air
* Clang installed from Homebrew llvm package automatically finds the
libc++ also provided as part of that package
It seems only IWYU forcefully adds magic paths, and it causes
problems for folks who want to do the right thing and build the sysroot
themselves. So remove these hard-coded paths.
If there is no installation of libc++ discoverable to Clang's probing,
or an alternative libc++ is desired, users can disable probing and
specify relevant paths directly on command-line:
# for Homebrew version of llvm-14
include-what-you-use -nostdinc++ \
-isystem /opt/homebrew/opt/llvm\@14/include/c++/v1 \
sourcefile.cc
# for Apple Command Line Tools version of libc++
include-what-you-use -nostdinc++ \
-isystem /Library/Developer/CommandLineTools/usr/include/c++/v1 \
sourcefile.cc
The mechanics of this technique is described in more detail for Clang:
https://libcxx.llvm.org//UsingLibcxx.html#using-a-custom-built-libc.
Co-authored-by: Kim Gräsman <kim.grasman@gmail.com>
IWYU doesn't produce any outputs, so -save-temps does not have any useful
effect.
Before this patch, passing -save-temps did, however, generate multiple
compilation jobs which caused a fatal error:
error: unable to handle compilation, expected exactly one compiler job
Filter the arguments out, similar to what Clang tools do by default.
Fixes issue #1060.
llvm/llvm-project@777180a makes the llvm::StringRef conversion operator
to std::string explicit.
These changes add a call to the str() method to perform the conversion.
Signed-off-by: Andrea Bocci <andrea.bocci@cern.ch>
For some reason, when Clang went from:
using llvm::opt::ArgStringList;
to
using ArgStringList = llvm::opt::ArgStringList;
my GCC no longer considers ArgStringList part of the clang::driver
namespace.
Use the qualified name llvm::opt::ArgStringList as was subsequently done
in clang-interpreter in r344400.
No functional change.
HeaderSearchOpts.ResourceDir is never empty, so this code would never
execute.
Besides, it's too late to set the resource dir here; it's already been
used in Driver::BuildCompilation to build toolchain paths relative to
the compiler executable.
NULL/0 -> nullptr
C standard library include -> C++ counterparts
Occasional use of auto
Explicit strcmp return value check
Remove unused usings
Closing comments for anonymous namespaces
In Clang r172904 bitreader dependency was introduced (CMake build succeeds
without bitreader dependency).
In Clang r172945 argc, argv were removed from createDiagnostics.
Changes of particular note:
* Resolved merge conflicts in:
third_party/llvm/libcxx/src/exception.cpp
third_party/llvm/llvm/tools/clang/lib/Driver/Tools.cpp
third_party/llvm/llvm/tools/clang/tools/driver/cc1_main.cpp
* Manual edits to
third_party/llvm/llvm/tools/clang/lib/Tooling/Tooling.cpp
due to diagnostic classes renaming
* Fixed up Cymbal, Grok and IWYU code for various class renamings
R=chandlerc,csilvers,chrsmith
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3337
This fixes an issue I ran across where I couldn't inhibit the forward declaration
of a symbol defined in an anonymous namespace.
R=csilvers
DELTA=59 (53 added, 0 deleted, 6 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=3326
statements for cast, isa, and dyn_cast. I don't know what's
changed (maybe upstream took out a using statement somewhere
that we were depending on?), but it was our bad in the first
place, so I'm happy to fix it.
Because we try not to use using statements in .h files, I just
prefixed ::llvm:: there when appropriate.
R=wan
DELTA=13 (8 added, 0 deleted, 5 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=2674
test some main()-invariant logic while I'm at it.
DELTA=19 (16 added, 0 deleted, 3 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1409
thought I was saying the location is where the . (or ->) is,
which is what I want, but clang doesn't actually expose that.
So I have go through some hoops to try to figure it out.
We were actually seeing a problem with this when running:
blaze build --host_cpu=k8 --compile_only -k --crosstool_top=//third_party/llvm/crosstool --plugin=//devtools/maintenance/include_what_you_use:run_iwyu //gws/plugins/local/src:enhanced_listing_ad
It has 'msg_->MSG_foo' in it, where MSG_foo is a macro. We
were attributing this use to the file defining MSG_foo, rather
than to us. With this change, we properly attribute it to us.
R=dsturtevant
DELTA=150 (125 added, 6 deleted, 19 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=1347
makes iwyu.cc cleaner.
For now, we use it only for iwyu_tests.cc, which needs
InitGlobal() to be called, which needs a CompilerInstance.
DELTA=516 (285 added, 210 deleted, 21 changed)
Revision created by MOE tool push_codebase.
MOE_MIGRATION=919
Sameer Rahmani
Kim Gräsman