Summary:
clangToolingCore is linked into almost everything (incl. clang), but
not few tools need #include manipulation at this point. So pull this into a
separate library in Tooling.
Reviewers: ilya-biryukov
Subscribers: klimek, mgorny, cfe-commits, thakis
Differential Revision: https://reviews.llvm.org/D47068
llvm-svn: 332720
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
Explicitly avoided changing the strings in the clang-format tests.
Differential Revision: https://reviews.llvm.org/D44975
llvm-svn: 332350
Summary: This will be shared by include insertion/deletion library.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: mgorny, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D46758
llvm-svn: 332284
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
Summary:
"-std c++11" is not valid in compiler, we have to use "-std=c++11".
Test in vscode with this patch, code completion for header works as expected.
Reviewers: sammccall
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D45512
llvm-svn: 329786
Avoid storing duplicated "std::string"s.
clangd's global-symbol-builder takes 20+GB memory running across LLVM
repository. With this patch, the used memory is ~10GB (running on 48
threads, most of meory are AST-related).
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45479
llvm-svn: 329784
Summary:
The wrapper finds the closest matching compile command using filename heuristics
and makes minimal tweaks so it can be used with the header.
Subscribers: klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D45006
llvm-svn: 329580
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
r327219 added wrappers to std::sort which randomly shuffle the container before
sorting. This will help in uncovering non-determinism caused due to undefined
sorting order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of
std::sort.
llvm-svn: 328636
Summary:
Noticed during review of D41102.
I'm not sure whether there are any principal reasons why it returns raw owning pointer,
or it is just a old code that was not updated post-C++11.
I'm not too sure what testing i should do, because `check-all` is not error clean here for some reason,
but it does not //appear// asif those failures are related to these changes.
This is clang part.
Clang-tools-extra part is D43780.
Reviewers: klimek, bkramer, alexfh, pcc
Reviewed By: alexfh
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D43779
llvm-svn: 326201
Summary:
The parameter overrides the underlying vfs used by ClangTool for
filesystem operations.
Patch by Vladimir Plyashkun.
Reviewers: alexfh, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D41947
llvm-svn: 323195
Summary:
As result deduplication or reduction is not supported in the framework,
we should leave the deplication to tools (if needed) until the framework supports it.
Reviewers: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42111
llvm-svn: 322691
Summary: Tool results are deduplicated by the result key.
Reviewers: hokein
Subscribers: klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D41729
llvm-svn: 321864
Summary: Provide default implementations so that only getCompileCommands() is mandatory.
Reviewers: ioeric
Subscribers: cfe-commits, bkramer, klimek
Differential Revision: https://reviews.llvm.org/D40409
llvm-svn: 318943
Summary:
The ArgumentsAdjuster returned from `getClangStripDependencyFileAdjuster` will
skip dependency flags, and also their associated values for those flags that
take an argument. This change corrects the handling of the `-MD` and `-MMD`
flags, which do not take an argument.
Reviewers: saugustine, klimek, alexshap
Reviewed By: alexshap
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40024
llvm-svn: 318529
Summary:
This is an alternative to JSONCompilationDatabase for simple projects that
don't use a build system such as CMake.
(You can also drop one in ~, to make your tools use e.g. C++11 by default)
There's no facility for varying flags per-source-file or per-machine.
Possibly this could be accommodated backwards-compatibly using cpp, but even if
not the simplicity seems worthwhile for the cases that are addressed.
Tested with clangd, works great! (requires clangd restart)
Reviewers: klimek
Subscribers: ilya-biryukov, cfe-commits
Differential Revision: https://reviews.llvm.org/D39799
llvm-svn: 317777
Summary:
The OccurrencesFinder is only used in RenameOccurrences to find symbol
occurrences, there is no need to inherit RefactoringRule.
Replace it with a single utility function to avoid code misleading.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D39796
llvm-svn: 317696
Summary:
For code reuse in SemaCodeComplete.
Note that the tests for QualTypeNames are still in Tooling as they use
Tooling's common testing code.
Reviewers: rsmith, saugustine, rnk, klimek, bkramer
Reviewed By: rnk
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D39224
llvm-svn: 317676
when needed
This commit implements the semicolon insertion logic into the extract
refactoring. The following rules are used:
- extracting expression: add terminating ';' to the extracted function.
- extracting statements that don't require terminating ';' (e.g. switch): add
terminating ';' to the callee.
- extracting statements with ';': move (if possible) the original ';' from the
callee and add terminating ';'.
- otherwise, add ';' to both places.
Differential Revision: https://reviews.llvm.org/D39441
llvm-svn: 317343
This commit changes the way that the refactoring operation classes are
structured:
- Users have to call `initiate` instead of constructing an instance of the
class. The `initiate` is now supposed to have custom initiation logic, and
you don't need to subclass the builtin requirements.
- A new `describe` function returns a structure with the id, title and the
description of the refactoring operation.
The refactoring action classes are now placed into one common place in
RefactoringActions.cpp instead of being separate.
Differential Revision: https://reviews.llvm.org/D38985
llvm-svn: 316780
Summary:
This defines a `clang::tooling::ToolExecutor` interface that can be extended to support different execution plans including standalone execution on a given set of TUs or parallel execution on all TUs in a codebase.
In order to enable multiprocessing execution, tool actions are expected to output result into a `ToolResults` interface provided by executors. The `ToolResults` interface abstracts how results are stored e.g. in-memory for standalone executions or on-disk for large-scale execution.
New executors can be registered as `ToolExecutorPlugin`s via the `ToolExecutorPluginRegistry`. CLI tools can use `createExecutorFromCommandLineArgs` to create a specific registered executor according to the command-line arguments.
This patch also implements `StandaloneToolExecutor` which has the same behavior as the current `ClangTool` interface, i.e. execute frontend actions on a given set of TUs. At this point, it's simply a wrapper around `ClangTool` at this point.
This is still experimental but expected to replace the existing `ClangTool` interface so that specific tools would not need to worry about execution.
Reviewers: klimek, arphaman, hokein, sammccall
Reviewed By: klimek
Subscribers: cfe-commits, djasper, mgorny, omtcyfz
Differential Revision: https://reviews.llvm.org/D34272
llvm-svn: 316653
This commit adds an initial, skeleton outline of the "extract function"
refactoring. The extracted function doesn't capture variables / rewrite code
yet, it just basically does a simple copy-paste.
The following initiation rules are specified:
- extraction can only be done for executable code in a function/method/block.
This means that you can't extract a global variable initialize into a function
right now.
- simple literals and references are not extractable.
This commit also adds support for full source ranges to clang-refactor's test
mode.
Differential Revision: https://reviews.llvm.org/D38982
llvm-svn: 316465
Summary: This returns error instead of exiting the program in case of error.
Reviewers: klimek, hokein
Reviewed By: hokein
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39042
llvm-svn: 316433
GCC tries to shorten system headers in depfiles using its real path
(resolving components like ".." and following symlinks). Mimic this
feature to ensure that the Ninja build tool detects the correct
dependencies when a symlink changes directory levels, see
https://github.com/ninja-build/ninja/issues/1330
An option to disable this feature is added in case "these changed header
paths may conflict with some compilation environments", see
https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00287.html
Note that the original feature request for GCC
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974) also included paths
preprocessed output (-E) and diagnostics. That is not implemented now
since I am not sure if it breaks something else.
Differential Revision: https://reviews.llvm.org/D37954
llvm-svn: 316193
consecutive statements
This commit adds a CodeRangeASTSelection value to the refactoring library. This
value represents a set of selected statements in one body of code.
Differential Revision: https://reviews.llvm.org/D38835
llvm-svn: 316104
Summary:
* Support rename alias.
* Add unittests for renaming alias.
* Don't generate fixes for the SourceLocations that are invalid or in temporary
buffer, otherwise crash would be happened when generating AtomicChanges.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D39043
llvm-svn: 316074
This commit allows the refactoring library to use its own set of
refactoring-specific diagnostics to reports things like initiation errors.
Differential Revision: https://reviews.llvm.org/D38772
llvm-svn: 315924
Summary:
Also contain a fix:
* Fix a false positive of renaming a using shadow function declaration.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D38882
llvm-svn: 315898
The recommit fixes a UB bug that occurred only on a small number of bots.
Original message:
This commit adds initial support for refactoring options. One can now use
optional and required std::string options.
This commit also adds a NewNameOption for the local-rename refactoring action to
allow rename to work with custom names.
Differential Revision: https://reviews.llvm.org/D37856
llvm-svn: 315661
This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
llvm-svn: 315536
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Differential Revision: https://reviews.llvm.org/D38767
llvm-svn: 315530
This commit adds initial support for refactoring options. One can now use
optional and required std::string options.
This commit also adds a NewNameOption for the local-rename refactoring action to
allow rename to work with custom names.
Differential Revision: https://reviews.llvm.org/D37856
llvm-svn: 315087
This commit simplifies the interface for the refactoring action rules and the
refactoring requirements. It merges the selection constraints and the selection
requirements into one class. The refactoring actions rules must now be
implemented using subclassing instead of raw function / lambda pointers. This
change also removes a bunch of template-based traits and other
template definitions that are now redundant.
Differential Revision: https://reviews.llvm.org/D37681
llvm-svn: 314704
This commit ensures that CommonOptionsParser works with subcommands. This allows
clang-refactor to use the CommonOptionsParser.
Differential Revision: https://reviews.llvm.org/D37618
llvm-svn: 313260
local-rename action
This commit introduces the clang-refactor tool alongside the local-rename action
which uses the existing renaming engine used by clang-rename. The tool
doesn't actually perform the source transformations yet, it just provides
testing support. This commit also moves only one test from clang-rename over to
test/Refactor. I will continue to move the other tests throughout
development of clang-refactor.
The following options are supported by clang-refactor:
-v: use verbose output
-selection: The source range that corresponds to the portion of the source
that's selected (currently only special command test:<file> is supported).
Please note that a follow-up commit will migrate clang-refactor to
libTooling's common option parser, so clang-refactor will be able to use
the common interface with compilation database and options like -p, -extra-arg,
etc.
The testing support provided by clang-refactor is described below:
When -selection=test:<file> is given, clang-refactor will parse the selection
commands from that file. The selection commands are grouped and the specified
refactoring action invoked by the tool. Each command in a group is expected to
produce an identical result. The precise syntax for the selection commands is
described in a comment in TestSupport.h.
Differential Revision: https://reviews.llvm.org/D36574
llvm-svn: 313244
Summary:
The use case is that renaming multiple symbols in a large enough codebase is
much faster if all of these can be done with a single invocation, but
there will be multiple translation units where one or more symbols are
not found.
Old behavior was to exit with an error (default) or exit without
reporting an error (-force). New behavior is that -force results in a
best-effort rename: rename symbols which are found and just ignore the
rest.
The existing help for -force sort of already implies this behavior.
Reviewers: cfe-commits, klimek, arphaman
Reviewed By: klimek
Differential Revision: https://reviews.llvm.org/D37634
llvm-svn: 312942
form of PseudoObjectExpr
The new commit adjusts unittest test code compilation options so that the
Objective-C code in the unittest can be parsed on non-macOS platforms.
Original message:
The AST selection finder now constructs a selection tree that contains only the
syntactic form of PseudoObjectExpr. This form of selection tree is more
meaningful when doing downstream analysis as we're interested in the syntactic
features of the AST and the correct lexical parent relation.
llvm-svn: 312132
of PseudoObjectExpr
The AST selection finder now constructs a selection tree that contains only the
syntactic form of PseudoObjectExpr. This form of selection tree is more
meaningful when doing downstream analysis as we're interested in the syntactic
features of the AST and the correct lexical parent relation.
llvm-svn: 312127
Information about clang executable name components, such as target and
driver mode, was passes in std::pair. With this change it is passed in
a special structure. It improves readability and makes access to this
information more convenient.
NFC.
Differential Revision: https://reviews.llvm.org/D36057
llvm-svn: 311981
This patch implements the initial support for refactoring action rules. The
first rule that's supported is a "source change" rule that returns a set of
atomic changes. This patch is based on the ideas presented in my RFC:
http://lists.llvm.org/pipermail/cfe-dev/2017-July/054831.html
The following pieces from the RFC are added by this patch:
- `createRefactoringRule` (known as `apply` in the RFC)
- `requiredSelection` refactoring action rule requirement.
- `selection::SourceSelectionRange` selection constraint.
Differential Revision: https://reviews.llvm.org/D36075
llvm-svn: 311884
This commit adds the base AST source selection component to the refactoring
library. AST selection is represented using a tree of SelectedASTNode values.
Each selected node gets its own selection kind, which can actually be None even
in the middle of tree (e.g. statement in a macro whose child is in a macro
argument). The initial version constructs a "raw" selection tree, without
applying filters and canonicalisation operations to the nodes.
Differential Revision: https://reviews.llvm.org/D35012
llvm-svn: 311655
Summary:
If a node referring to a name is within a class or namespace, do not use
the full qualified name, but strip the namespace prefix.
Reviewers: arphaman, bkramer
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D36681
llvm-svn: 311433
Summary:
Add separate tests for the top-down and the bottom-up phase, as well as
one for the optimal matching.
Reviewers: arphaman
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D36185
llvm-svn: 311284
Summary:
Ignore macros and implicit AST nodes, as well as anything outside of the
main source file.
Reviewers: arphaman
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D36184
llvm-svn: 311280
Summary:
Until we find a decent heuristic on how to choose between multiple
identical trees, there is no point in supporting multiple mappings.
This also enables matching of nodes with parents of different types,
because there are many instances where this is appropriate. For
example for and foreach statements; functions in the global or
other namespaces.
Reviewers: arphaman
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D36183
llvm-svn: 311251
Summary:
This also changes the output order of the changes. Now the matches are
printed in pre-order, intertwined with insertions, updates, and moves.
Deletions are printed afterwards.
Reviewers: arphaman
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D36179
llvm-svn: 311200
Fix to the computation of the rightmost descendant.
Prevents root nodes from being mapped if they are already mapped. This
only makes a difference when we compare AST Nodes other than entire
translation units, a feature which still has to be tested.
Reviewers: arphaman
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D36176
llvm-svn: 311172
Summary:
If assertions are disabled, but LLVM_ABI_BREAKING_CHANGES is enabled,
this will cause an issue with an unchecked Success. Switching to
consumeError() is the correct way to bypass the check.
Reviewers: llvm-commits, cfe-commits, arphaman
Reviewed By: arphaman
Subscribers: arphaman, klimek, pirama
Differential Revision: https://reviews.llvm.org/D36728
llvm-svn: 310958
Symbol occurrences store the results of local rename and will also be used for
the global, indexed rename results. Their kind is used to determine whether they
should be renamed automatically or not. They can be converted to a set of
AtomicChanges as well.
Differential Revision: https://reviews.llvm.org/D36156
llvm-svn: 310853
std::pair in emplace back couldn't be constructed because SNodeId has an
explicit constructor. Not sure how this even compiled on my machine before.
llvm-svn: 308734
This is the first commit for the "Clang-based C/C++ diff tool" GSoC project.
ASTDiff is a new library that computes a structural AST diff between two ASTs
using the gumtree algorithm. Clang-diff is a new Clang tool that will show
the structural code changes between different ASTs.
Patch by Johannes Altmanninger!
Differential Revision: https://reviews.llvm.org/D34329
llvm-svn: 308731
D34304 created a way for ToolInvocations to conditionally generate
dependency files, and updated call sites to preserve the old behavior
of not generating them by default. CompilerInvocations...
Summary:
...are yet another
call-path that needs updating to preserve the old behavior.
Reviewers: klimek, echristo
Reviewed By: echristo
Subscribers: echristo, cfe-commits
Differential Revision: https://reviews.llvm.org/D35131
llvm-svn: 308043
a declaration at location and for class that searches for all occurrences of
a specific declaration
This commit uses a single RecursiveSymbolVisitor class for both
USRLocFindingASTVisitor and NamedDeclOccurrenceFindingVisitor to avoid duplicate
traversal code. It also traverses nested name specifier locs in the new class
and remove the separate matching step.
Differential Revision: https://reviews.llvm.org/D34949
llvm-svn: 307898
Summary: Use an argument adjuster to preserve behavior inadvertantly changed by D34304.
Reviewers: klimek
Differential Revision: https://reviews.llvm.org/D35095
llvm-svn: 307329
Summary:
Most clang tools should ignore the -M
family of options because one wouldn't want them
to generate a new dependency (.d) file. However,
some tools may want this dependency file. This
patch creates a mechanism for them to do this.
This implementation just plumbs a boolean down
several layers of calls. Each of the modified calls
has several call sites, and so a single member
variable or new API entry point won't work.
An alternative would be to write a function to filter
the -M family of arguments out of CC1Args, and have
each caller call that function by hand before calling
newInvocation, Invocation::run, or buildAstFromCodeWithArgs.
This is a more complicated and error-prone solution.
Why burden all the callers to remember to use
this function?
But I could rewrite this patch to use that method if
that is deemed more appropriate.
Reviewers: klimek
Reviewed By: klimek
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D34304
llvm-svn: 307315
This is a short-term fix for PR33650 aimed to get the modules build bots green again.
Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.
Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)
Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.
Differential Revision: https://reviews.llvm.org/D34907
Corresponding LLVM change is r306878.
llvm-svn: 306881
arguments when `-fsyntax-only` is used
Previously, Clang failed to create a fixed compilation database when the
compilation arguments use -fsyntax-only instead of -c. This commit fixes the
issue by forcing Clang to look at the compilation job when stripping the
positional arguments.
Differential Revision: https://reviews.llvm.org/D34687
llvm-svn: 306659
Now FixedCompilationDatabase::loadFromCommandLine has no means to report
which error occurred if it fails to create compilation object. This is
a block for implementing D33013, because after that change driver will
refuse to create compilation if command line contains erroneous options.
This change adds additional argument to loadFromCommandLine, which is
assigned error message text if compilation object was not created. This is
the same way as other methods of CompilationDatabase report failure.
Differential Revision: https://reviews.llvm.org/D33272
llvm-svn: 303741
This diff
1. adds missing "explicit" for single argument constructors
2. adds missing std::move in ReplaceNodeWithTemplate constructor
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D33061
llvm-svn: 302855
Summary: This is the first change as part of developing a clang-query based search and replace tool.
Reviewers: klimek, bkramer, ioeric, sbenza, jbangert
Reviewed By: ioeric, jbangert
Subscribers: sbenza, ioeric, cfe-commits
Patch by Julian Bangert!
Differential Revision: https://reviews.llvm.org/D29621
llvm-svn: 302624
Summary: ... which applies a set of `AtomicChange`s on code.
Reviewers: klimek, djasper
Reviewed By: djasper
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30777
llvm-svn: 298913
Summary:
An AtomicChange is used to create and group a set of source edits, e.g.
replacements or header insertions. Edits in an AtomicChange should be related,
e.g. replacements for the same type reference and the corresponding header
insertion/deletion.
An AtomicChange is uniquely identified by a key position and will either be
fully applied or not applied at all. The key position should be the location
of the key syntactical element that is being changed, e.g. the call to a
refactored method.
Next step: add a tool that applies AtomicChange.
Reviewers: klimek, djasper
Reviewed By: klimek
Subscribers: alexshap, cfe-commits, djasper, mgorny
Differential Revision: https://reviews.llvm.org/D27054
llvm-svn: 296616
Change the contract of GetStyle so that it returns an error when an error occurs
(i.e. when it writes to stderr), and only returns the fallback style when it
can't find a configuration file.
Differential Revision: https://reviews.llvm.org/D28081
llvm-svn: 292174
Aleksey Shlypanikov pointed out my mistake in migrating an explicit
unique_ptr to auto - I was expecting the function returned a unique_ptr,
but instead it returned a raw pointer - introducing a leak.
Thanks Aleksey!
This reapplies r291184, reverted in r291249.
llvm-svn: 291270
Add a field indicating the associated check for every replacement to the YAML
report generated with the '-export-fixes' option. Update
clang-apply-replacements to handle the new format.
Patch by Alpha Abdoulaye!
Differential revision: https://reviews.llvm.org/D26137
llvm-svn: 290892
In bigger projects like an Operating System, the same source code is
often compiled in slightly different ways. This could be the difference
between PIC and non-PIC code for static vs dynamic libraries, it could
also be the difference between size optimised versions of tools for
ramdisk images. At the moment, the compilation database has no way to
distinguish such cases. As first step, add a field in the JSON format
for it and process it accordingly.
Differential Revision: https://reviews.llvm.org/D27138
llvm-svn: 288436
Summary:
If the `FromDecl` is a class forward declaration, the reference is
still considered as referring to the original definition given the nature
of forward-declarations, so we can't do a raw name replacement in this case.
Reviewers: bkramer
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D27132
llvm-svn: 287929
Summary:
For example, this case was missed when looking for different but canonical
namespaces. UseContext in this case should be considered as in the canonical
namespace.
```
namespace a { namespace b { <FromContext> } }
namespace a { namespace b { namespace c { <UseContext> } } }
```
Added some commenting.
Reviewers: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D27125
llvm-svn: 287924
Summary:
The new error information contains the type of error (e.g. overlap or bad file path)
and the replacement(s) that is causing the error. This enables us to resolve some errors.
For example, for insertion at the same location conflict, we need to know the
existing replacement which conflicts with the new replacement in order to calculate
the new position to be insert before/after the existing replacement (for merging).
Reviewers: klimek, bkramer
Subscribers: djasper, cfe-commits
Differential Revision: https://reviews.llvm.org/D26853
llvm-svn: 287639
Summary:
The current version does not deduplicate equivalent file paths correctly.
For example, a relative path and an absolute path are considered inequivalent.
Comparing FileEnry addresses these issues.
Reviewers: djasper
Subscribers: alexshap, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D26288
llvm-svn: 286096
Summary:
If there are multiple <File, Replacements> pairs with the same file
path after removing dots, we only keep one pair (with path after dots being
removed) and discard the rest.
Reviewers: djasper
Subscribers: klimek, hokein, bkramer, cfe-commits
Differential Revision: https://reviews.llvm.org/D25565
llvm-svn: 284219
This diff adds std::move to avoid copying of
the Replacement NewR in the method Replacements::add.
Test plan: make -j8 check-all
Differential revision: https://reviews.llvm.org/D25049
llvm-svn: 282949
Summary:
Now two replacements are considered order-independent if applying them in
either order produces the same result. These include (but not restricted
to) replacements that:
- don't overlap (being directly adjacent is fine) and
- are overlapping deletions.
- are insertions at the same offset and applying them in either order
has the same effect, i.e. X + Y = Y + X if one inserts text X and the
other inserts text Y.
Discussion about this design can be found in D24717
Reviewers: djasper, klimek
Subscribers: omtcyfz, cfe-commits
Differential Revision: https://reviews.llvm.org/D24800
llvm-svn: 282577
Summary:
Diff to r281457:
- added a test case `CalculateRangesOfInsertionAroundReplacement`.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D24606
llvm-svn: 281891
Summary:
No behavioral change intended. The change makes iterating the replacements set more intuitive in Replacements class implementation. Previously, insertion is ordered before an deletion/replacement with the same offset, which is counter-intuitive for implementation, especially for a followup patch to support adding insertions around replacements.
With the current ordering, we only need to make `applyAllReplacements` iterate the replacements set reversely when applying them so that deletion/replacement is still applied before insertion with the same offset.
Reviewers: klimek, djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D24663
llvm-svn: 281819
Summary:
Extend `tooling::Replacements::add()` to support adding order-independent replacements.
Two replacements are considered order-independent if one of the following conditions is true:
- They do not overlap. (This is already supported.)
- One replacement is insertion, and the other is a replacement with
length > 0, and the insertion is adjecent to but not contained in the
other replacement. In this case, the replacement should always change
the original code instead of the inserted text.
Reviewers: klimek, djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D24515
llvm-svn: 281457
Eric Liu