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
This diff removes unnecessary using of unique_ptr with ClangMoveActionFactory (pico cleanup).
NFC
Test plan: make check-clang-tools
Differential revision: https://reviews.llvm.org/D32063
llvm-svn: 300356
Summary:
Also ignore helpers which are defined in macro. Currently clang-move doesn't
handle macro well enough, especiall for complex macros. This patch will ignore
declarations in macros to make the behavior of clang-move more correct.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28774
llvm-svn: 292207
Summary:
Instead of moving all the helper declarations blindly, this patch
implements an AST-based call graph solution to make clang-move only move used
helper decls to new.cc and remove unused decls in old.cc.
Depends on D27674.
Reviewers: ioeric
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D27673
llvm-svn: 290873
1. Remove some boilerplate code for appending -fparse-all-comments to the list of arguments.
2. Run clang-format -i against ClangMoveMain.cpp.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D27669
llvm-svn: 289464
Summary:
* Add -dump_dels option to dump all declarations from old header. It
will allow clang-move used as a frontend to get declarations from
header. Further more, this will make debugging stuff easier. Currently only
class/function types are supported.
* Refactoring code a little bit by creating a ClangMoveContext which
holds all options for ClangMoveTool, which can simplify the code in
some degree.
Reviewers: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27059
llvm-svn: 287863
Summary:
* --new_depend_on_old: new header will include old header
* --old_depend_on_new: old header will include new header.
Reviewers: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26966
llvm-svn: 287752
Summary:
Add decent blank lines between declarations:
* Add extra blank line after #define or #includes.
* Add extra blank line between declarations.
* Add extra blank line in front of #endif.
Previously, the new generated code is quite tight:
```
#ifndef FOO_H
#define FOO_H
namespace a {
class A { public: int f(); };
int A::f() { return 0; }
} // namespace a
#endif // FOO_H
```
After this patch, the code looks like:
```
#ifndef FOO_H
#define FOO_H
namespace a {
class A { public: int f(); };
int A::f() { return 0; }
} // namespace a
#endif // FOO_H
```
Reviewers: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26493
llvm-svn: 286943
Summary:
Fix an incorrect range for the functions whose returned value is a macro
(e.g. `bool`). This incorrect range can lead to modifications of an unexpected
file where the macro is in.
We should use expansion location instead of spelling location.
Reviewers: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26609
llvm-svn: 286833
Summary:
No functionality change.
This is a refactoring patch, which makes the code more readable and easy
to extend it to support more types.
Reviewers: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26515
llvm-svn: 286825
Summary: When moving all code to new.h/cc, these code also will be formatted based on the given code style.
Reviewers: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26236
llvm-svn: 286281
The filepath might contain some characters (i.e. '@') which are not
illegal in c identifiers. This patch changes all non-alphanumeric characters
to '_'.
llvm-svn: 284391
This diff replaces manual parsing of the comma-separated list of names with
cl::list and cl::CommaSeparated.
Test plan: make -j8 check-clang-tools
Differential revision: https://reviews.llvm.org/D25586
llvm-svn: 284291
Summary:
The header guard generated by clang-move isn't always a perfect
style, just avoid getting the header included multiple times during
compiling period.
Also, we can use llvm-Header-guard clang-tidy check to correct the guard
automatically.
Reviewers: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25610
llvm-svn: 284233
Summary:
* When moving an outermost enclosing class, all its nested classes should also
be moved together.
* Add a test for not moving nested class.
Reviewers: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25369
llvm-svn: 284111
Summary: MakeAbsolutePath does wrong things with symlinks previously. When comparing with a symlink, we need to compare with the real path of it. This fixes issues when the build directory is a symlink.
Reviewers: ioeric
Subscribers: beanz, mgorny, cfe-commits, bkramer
Differential Revision: https://reviews.llvm.org/D25508
llvm-svn: 284020
This reverts commit r283526 et al as it keeps randomly breaking bots, even after
the commit has gone, on other people's commit ranges.
Revert "[clang-move] Simplify lint tests" (r283545).
Revert "Fix buildbot error." (r283534).
Revert "Revert "fix buildbot error" since it is not right fix." (r283538).
llvm-svn: 283553
Summary:
cleanup the remaining empty namespace after moving out the
class defintitions.
Reviewers: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25282
llvm-svn: 283424
Summary:
Previously, all #includes (includeing old_header.h) in old.cc will be copied to new.cc,
however, the new.cc should include new_header.h instead of the old_header.h
Before applying the patch, the new.cc looks like:
```
#include "old_header.h"
...
```
The new.cc looks like with this patch:
```
#include "new_header"
...
```
Reviewers: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24828
llvm-svn: 282247
Shoaib Meenai