| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against
libclang_shared.so instead of the individual component libraries.
Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru
Subscribers: arphaman, cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63503
llvm-svn: 365092
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fix -DBUILD_SHARED_LIBS=on build
This is a more thorough fix of rC348911.
The story about -DBUILD_SHARED_LIBS=on build after rC348907 (Move PCHContainerOperations from Frontend to Serialization) is:
1. libclangSerialization.so defines PCHContainerReader dtor, ...
2. clangFrontend and clangTooling define classes inheriting from PCHContainerReader, thus their DSOs have undefined references on PCHContainerReader dtor
3. Components depending on either clangFrontend or clangTooling cannot be linked unless they have explicit dependency on clangSerialization due to the default linker option -z defs. The explicit dependency could be avoided if libclang{Frontend,Tooling}.so had these undefined references.
This patch adds the explicit dependency on clangSerialization to make them build.
llvm-svn: 348915
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Print negative numbers correctly
- Handle APInts of different sizes
- Add formal unit tests for FixedPointValueToString
- Add tests for checking correct printing when padding is set
- Restrict to printing in radix 10 since that's all we need for now
Differential Revision: https://reviews.llvm.org/D49945
llvm-svn: 339026
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by: krisb
Reviewers: teemperor
Reviewed By: teemperor
Subscribers: klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D43809
llvm-svn: 326566
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fixed commit ensures that ParsedSourceRange works correctly
with Windows paths.
Original message:
This commit actually brings clang-refactor to a usable state as it can now
apply the refactoring changes to source files.
The -selection option is now also fully supported.
Differential Revision: https://reviews.llvm.org/D38402
llvm-svn: 315918
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The CompilerInstance should create its default VFS from its CompilerInvocation. Right now the
user has to manually create the VFS before creating the FileManager even though
`-ivfsoverlay file.yaml` was passed via the CompilerInvocation (which is exactly how we worked
around this issue in `FrontendAction.cpp` so far).
This patch uses the invocation's VFS by default and also tests this behavior now from the
point of view of a program that uses the clang API.
Reviewers: benlangmuir, v.g.vassilev
Reviewed By: v.g.vassilev
Subscribers: mgorny, cfe-commits, v.g.vassilev
Differential Revision: https://reviews.llvm.org/D37416
llvm-svn: 313049
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using a virtual file-system (VFS) and a preamble file (PCH) is generated,
it is generated on-disk in the real file-system instead of in the VFS (which
makes sense, since the VFS is read-only). However, when subsequently reading
the generated PCH, the frontend passes through the VFS it has been given --
resulting in an error and a failed parse (since the VFS doesn't contain the
PCH; the real filesystem does).
This patch fixes that by detecting when a VFS is being used for a parse that
needs to work with a PCH file, and creating an overlay VFS that includes the
PCH file from the real file-system.
This allows tests to be written which make use of both PCH files and a VFS.
Differential Revision: https://reviews.llvm.org/D37474
llvm-svn: 312917
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In ASTUnit::LoadFromASTFile, the context object is set up using
default-constructed LangOptions (which only later get populated). As the
language options are used in the constructor of PrintingPolicy, this
needs to be updated explicitly after the language options are available.
Patch by Johann Klähn!
Differential Revision: https://reviews.llvm.org/D35271
llvm-svn: 311787
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Llvm module object is shared between CodeGenerator and BackendConsumer,
in both classes it is stored as std::unique_ptr, which is not a good
design solution and can cause double deletion error. Usually it does
not occur because in BackendConsumer::HandleTranslationUnit the
ownership of CodeGenerator over the module is taken away. If however
this method is not called, the module is deleted twice and compiler crashes.
As the module owned by BackendConsumer is always the same as CodeGenerator
has, pointer to llvm module can be removed from BackendGenerator.
Differential Revision: http://reviews.llvm.org/D15450
llvm-svn: 261222
|
| |
|
|
|
|
| |
PR24067.
llvm-svn: 241915
|
| |
|
|
| |
llvm-svn: 220417
|
| |
|
|
| |
llvm-svn: 215177
|
| |
|
|
|
|
| |
CMakeLists.txt.
llvm-svn: 196916
|
| |
|
|
| |
llvm-svn: 172907
|
| |
|
|
|
|
| |
inline assembly.
llvm-svn: 161594
|
|
|
The fundamental change is to put a CMakeLists.txt file in the unittest
directory, with a single test binary produced from it. This has several
advantages.
Among other fundamental advantages, we start to get the checking logic
for when a file is missing from the CMake build, and this caught one
missing file already! More fun details in the LLVM commit corresponding
to this one.
Note that the LLVM commit and this one most both be applied, or neither.
Sorry for any skew issues.
llvm-svn: 158910
|
