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: 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
As reported in llvm bugzilla 32377.
Here’s a patch to add preinclude of stdc-predef.h.
The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.” See https://gcc.gnu.org/gcc-4.8/porting_to.html;
The preinclude is inhibited with –ffreestanding.
Basically I fixed the failing test cases by adding –ffreestanding which inhibits this behavior.
I fixed all the failing tests, including some in extra/test, there's a separate patch for that which is linked here
Note: this is a recommit after a test failure took down the original (r318669)
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158
llvm-svn: 320391
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 saves some cycles when compiling with "-w".
(Also fix a potential crash on invalid code for tools that tries to recover from some
errors, because analysis might compute the CFG which crashes if the code contains
invalid declaration. This does not happen normally with because we also don't perform
these analysis if there was an error.)
Differential Revision: https://reviews.llvm.org/D40242
llvm-svn: 318900
As reported in llvm bugzilla 32377.
Here’s a patch to add preinclude of stdc-predef.h.
The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.”
See https://gcc.gnu.org/gcc-4.8/porting_to.html;
The preinclude is inhibited with –ffreestanding.
Basically I fixed the failing test cases by adding –ffreestanding which inhibits
this behavior.
I fixed all the failing tests, including some in extra/test, there's a separate
patch for that which is linked here
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158
llvm-svn: 318669
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:
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
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
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
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
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 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
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:
This affects overloaded operators, which are represented by a
CXXOperatorCallExpr whose first child is always a DeclRefExpr referring to the
operator. For infix, postfix and call operators we want the first argument
to be traversed before the operator.
Reviewers: arphaman
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D37200
llvm-svn: 312633
Summary:
We need to specialize this because RecursiveASTVisitor visits template
template parameters after the templated declaration, unlike the order in
which they appear in the source code.
Reviewers: arphaman
Reviewed By: arphaman
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36998
llvm-svn: 312631
rule classes
This commit changes the way that the refactoring results are produced. Instead
of using different `RefactoringActionRule` subclasses for each result type,
Clang now use a single `RefactoringResultConsumer`. This was suggested by
Manuel in https://reviews.llvm.org/D36075.
Differential Revision: https://reviews.llvm.org/D37291
llvm-svn: 312316
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
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
Module builds somehow report an ambiguity between clang::Diagnostic and
clang::Tooling::Diagnostic. It seems as if one of the additional headers
brought in by the module brings the clang namespace to the toplevel. I
could not find out the reason for that, so for now I go with the simple
fix to bring the build back to green.
rdar://33321397
llvm-svn: 308071
Summary:
To get properly integration Clang-Tidy with CLion IDE, next things were implemented:
1) Preserve `Message`, `FileOffset`, `FilePath` in the clang-tidy output.
2) Export all diagnostics, not just the ones with fixes
3) Test-cases
Reviewers: klimek, ilya-biryukov, alexfh
Reviewed By: alexfh
Subscribers: alexfh, JDevlieghere, mgorny, xazax.hun, cfe-commits, klimek
Tags: #clang-tools-extra
Patch by Vladimir Plyashkun!
Differential Revision: https://reviews.llvm.org/D34404
llvm-svn: 308014
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
... once each for the syntactic and semantic form. Without this fix, behavior
of the newly added tests would have been
InitListExprIsPreOrderVisitedTwice:
syntactic: 1
semantic: 2
InitListExprIsPostOrderVisitedTwice:
syntactic: 0
semantic: 1
InitListExprIsPreOrderNoQueueVisitedTwice:
syntactic: 1
semantic: 2
InitListExprIsPostOrderNoQueueVisitedTwice:
syntactic: 0
semantic: 2
llvm-svn: 306374
...instead of -std=c99, as the latter lead to
error: invalid argument '-std=c99' not allowed with 'C++'
complaints in test logs
Differential Revision: https://reviews.llvm.org/D34417
llvm-svn: 306373
No-one was using this, and it's not meaningful in general -- FrontendActions
can be run on inputs that don't have a corresponding source file. The current
frontend input can be obtained by asking the FrontendAction if any future
action actually needs it.
llvm-svn: 305045
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
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
The previous algorithm processed one character at a time, which is very
painful on a modern CPU. Replace it with xxHash64, which both already
exists in the codebase and is fairly fast.
Patch from Scott Smith!
Differential Revision: https://reviews.llvm.org/D32509
llvm-svn: 301487
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
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
copy constructors of classes with array members, instead using
ArrayInitLoopExpr to represent the initialization loop.
This exposed a bug in the static analyzer where it was unable to differentiate
between zero-initialized and unknown array values, which has also been fixed
here.
llvm-svn: 289618
While C(++) and ObjC are generally formatted the same way and can be
mixed, people might want to choose different styles based on the
language. This patch recognizes .m and .mm files as ObjC and also
implements a very crude detection of whether or not a .h file contains
ObjC code. This can be improved over time.
Also move most of the ObjC tests into their own test file to keep file
size maintainable.
llvm-svn: 289428
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
On Windows, Clang is mangling lambdas in default member initializers
incorrectly. See PR31197.
This is causing redness on the self-host bots. Work around the problem
locally so we aren't blind to further issues.
llvm-svn: 288089
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:
The matcher
varDecl(hasDescendant(
callExpr(hasDeclaration(functionDecl(unless(isNoThrow()))))))
didn't match calls from default arguments because the expression
for a CXXDefaultArgExpr was not visited.
Reviewers: klimek, jdennett, alexfh, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D25992
llvm-svn: 285239
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
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:
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
r271042 changed the way the diagnostic arguments are parsed. It assumes that
the diagnostics options were already parsed by the "Driver".
For tools using clang::Tooling, the diagnostics argument were not parsed.
Differential Revision: https://reviews.llvm.org/D23837
llvm-svn: 280118
This patch introduced the ability to decide at runtime whether to parse
JSON compilation database command lines using Gnu syntax or Windows
syntax. However, there were many existing unit tests written that
hardcoded Gnu-specific paths. These tests were now failing because
the auto-detection logic was choosing to parse them using Windows
rules.
This resubmission of the patch fixes this by introducing an enum
which defines the syntax mode, which defaults to auto-detect, but
for which the unit tests force Gnu style parsing.
Reviewed By: alexfh
Differential Revision: https://reviews.llvm.org/D23628
llvm-svn: 279120
Summary:
rL277342 made RecursiveASTVisitor visit lambda capture initialization
expressions (these are the Exprs in LambdaExpr::capture_inits()).
jdennett identified two issues with rL277342 (see comments there for details):
- It visits initialization expressions for implicit lambda captures, even if
shouldVisitImplicitCode() returns false.
- It visits initialization expressions for init captures twice (because these
were already traveresed in TraverseLambdaCapture() before rL277342)
This patch fixes these issues and moves the code for traversing initialization
expressions into TraverseLambdaCapture().
This patch also makes two changes required for the tests:
- It adds Lang_CXX14 to the Language enum in TestVisitor.
- It adds a parameter to ExpectedLocationVisitor::ExpectMatch() that specifies
the number of times a match is expected to be seen.
Reviewers: klimek, jdennett, alexfh
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23204
llvm-svn: 278933
Previously, we would search through all replacements when inserting a
new one to check for overlaps. Instead, make use of the fact that we
already have a set of replacments without overlaps to find the potential
overlap with lower_bound.
Differential Revision: https://reviews.llvm.org/D23119
llvm-svn: 277597
Summary:
Lambda capture initializations are part of the explicit source code and
therefore should be visited by default but, so far, RecursiveASTVisitor does not
visit them.
This appears to be an oversight. Because the lambda body needs custom handling
(calling TraverseLambdaBody()), the DEF_TRAVERSE_STMT for LambdaExpr sets
ShouldVisitChildren to false but then neglects to visit the lambda capture
initializations. This patch adds code to visit the expressions associated with
lambda capture initializations.
Reviewers: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D22566
llvm-svn: 277342
Summary:
- Implement clang::tooling::Replacements as a class to provide interfaces to
control how replacements for a single file are combined and provide guarantee
on the order of replacements being applied.
- tooling::Replacements only contains replacements for the same file now.
Use std::map<std::string, tooling::Replacements> to represent multi-file
replacements.
- Error handling for the interface change will be improved in followup patches.
Reviewers: djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D21748
llvm-svn: 277335
Summary:
Lambda capture initializations are part of the explicit source code and therefore should be visited by default but, so far, RecursiveASTVisitor does not visit them.
This appears to be an oversight. Because the lambda body needs custom handling (calling TraverseLambdaBody()), the DEF_TRAVERSE_STMT for LambdaExpr sets ShouldVisitChildren to false but then neglects to visit the lambda capture initializations. This patch adds code to visit the expressions associated with lambda capture initializations.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D22566
llvm-svn: 276755
Summary:
[Tooling] skip anonymous namespaces when checking if typeLoc
references a type decl from a different canonical namespace.
Reviewers: bkramer
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D22808
llvm-svn: 276754
Summary:
return llvm::Expected<> to carry error status and error information.
This is the first step towards introducing "Error" into tooling::Replacements.
Reviewers: djasper, klimek
Subscribers: ioeric, klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D21601
llvm-svn: 275062
Summary:
Added calculateRangesAfterReplaments() to calculate original ranges as well as
newly affacted ranges in the new code.
Reviewers: klimek, djasper
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D21547
llvm-svn: 273290
Ilya Biryukov