| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 308733
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 307143
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
The core engine of clang-rename will be used for local and global renames in the
new refactoring engine, as mentioned in
http://lists.llvm.org/pipermail/cfe-dev/2017-June/054286.html.
The clang-rename tool is still supported but might get deprecated in the future.
Differential Revision: https://reviews.llvm.org/D34696
llvm-svn: 306840
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 302741
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: The Database check looks redundant.
Reviewers: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D32909
llvm-svn: 302236
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: alexshap, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D31492
llvm-svn: 299073
|
|
|
|
|
|
|
|
|
| |
This broke GreenDragon:
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA_build/4776/
Reverting this commit and all follow-up commits.
llvm-svn: 298967
|
|
|
|
| |
llvm-svn: 298965
|
|
|
|
| |
llvm-svn: 298921
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 298443
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Just realized the implementation is missing...
Reviewers: klimek
Reviewed By: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30735
llvm-svn: 297289
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 291919
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and CodeCompleteConsumer"
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
|
|
|
|
|
|
|
|
|
|
| |
CodeCompleteConsumer"
Caused a memory leak reported by asan. Reverting while I investigate.
This reverts commit r291184.
llvm-svn: 291249
|
|
|
|
|
|
| |
CodeCompleteConsumer
llvm-svn: 291184
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Bunch of fixed bugs in Clang after running misc-use-after-move in clang-tidy.
Reviewers: rsmith, mboehme
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D27752
llvm-svn: 290424
|
|
|
|
| |
llvm-svn: 289543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 287947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: aaron.ballman, mehdi_amini, dblaikie
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D26276
llvm-svn: 285899
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
As a side effect, this avoid having to call .data() on the StringRef.
llvm-svn: 283416
|
|
|
|
| |
llvm-svn: 283039
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 282583
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
length order first in the set.
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
|
|
|
|
|
|
| |
Commit was breaking our internal tests.
llvm-svn: 281557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 280187
|
|
|
|
| |
llvm-svn: 280186
|