This sorts based on the popularity of the header, not the symbol. If
there are mutliple matching symbols in one header we take the maximum
popularity for that header and deduplicate. If we know nothing we sort
lexicographically based on the header path.
Differential Revision: http://reviews.llvm.org/D20814
llvm-svn: 271283
Summary: [include-fixer] use tooling::Replacements since the order of replacements don't matter anymore.
Differential Revision: http://reviews.llvm.org/D20813
llvm-svn: 271279
Summary:
* Abstract the DB setting code to a function.
* Remove the unused FallbackStyle.
Reviewers: bkramer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20808
llvm-svn: 271273
Summary:
[include-fixer] collect the number of times a symbols is found in an
indexing run and use it for symbols popularity ranking.
Reviewers: bkramer
Subscribers: cfe-commits, hokein, djasper
Differential Revision: http://reviews.llvm.org/D20804
llvm-svn: 271268
Summary:
Some changes in the patch:
* Add two commandline flags in clang-include-fixer.
* Introduce a IncludeFixerContext for the queried symbol.
* Pull out CreateReplacementsForHeader.
Reviewers: bkramer
Subscribers: klimek, cfe-commits, ioeric
Differential Revision: http://reviews.llvm.org/D20621
llvm-svn: 271258
Summary: [include-fixer] moved STLPostfixMap into findAllSymbols library and make it a static variable in function.
Reviewers: bkramer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20619
llvm-svn: 270696
If a search string starts with "::" we don't want to return any results
for suffixes of that string.
Differential Revision: http://reviews.llvm.org/D20424
llvm-svn: 270055
This is used to find nested classes. For a nested name foo::bar::qux we
will first look up foo::bar::qux, then foo::bar, then foo unless we find
a result. This is used to support nested classes which are not part of
the index but can only be used if the header for the parent context is
included.
Differential Revision: http://reviews.llvm.org/D20372
llvm-svn: 269956
This typically happens when the user didn't setup include paths correctly
and the fixer starts adding garbage includes. Avoid that. Disable the error
limit though, as we might hit that easily with missing includes and still
want to fix those cases.
llvm-svn: 269923
Summary:
The InMemorySymbolIndex only constructs hard-coded Class symbols from a string
map. The patch provide a flexable way in InMemorySymbolIndex to create a custom
SymbolInfo in the include-fixer unittest.
Reviewers: bkramer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20232
llvm-svn: 269427
Summary:
Also change enums defined in SymbolInfo to scoped enums to avoid
conflicts.
Reviewers: bkramer
Subscribers: cfe-commits, ioeric
Differential Revision: http://reviews.llvm.org/D20203
llvm-svn: 269401
Summary:
The HeaderSearch::suggestPathToFileForDiagnostics used in include-fixer
doesn't work well with absolute file path, it assumes a relative file
path based on header searching path.
So saving relative file path to make include-fixer get the most
appropriate header path.
Reviewers: bkramer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20158
llvm-svn: 269173
Summary:
SymbolInfo has some optional fields, which is a bad-smell
implementation. For now, we
* remove the optional field since we don't need them (we can probably
add them back if we actually need them in the future)
* make SymbolInfo to be a class.
By this change, the code is more simplified.
Reviewers: klimek
Subscribers: cfe-commits, ioeric, bkramer
Differential Revision: http://reviews.llvm.org/D20095
llvm-svn: 269162
We already handled the case where we had a nested name specifier where
parts from the beginning don't get a callback, also handle the case
where the end doesn't get a callback. This happens with function calls
in unknown namespaces.
The way we do this for now based on character data is a bit of a hack, we
may need to refine this later or fix clang to produce different callbacks.
llvm-svn: 269029
We used a std::set which made the picked include somewhat random (well,
lexicographically sorted). Make the behavior more consistent by always
picking the first one we found.
llvm-svn: 269028
This looks for find_all_symbols_db.yaml in all parent directories of the
source file (like we do for compile_commands.json) so we don't have to
pass the path manually.
Differential Revision: http://reviews.llvm.org/D20066
llvm-svn: 268920
There is still more parallelism to get here because we synchonize on the
actual uniquing but just doing YAML parsing in parallel already gives a
significant speedup.
Merging all symbols in LLVM+clang+compiler-rt+lld+libc++, 48 cores.
before: 201.55s user 1.47s system 99% cpu 3:23.04 total
after: 276.99s user 7.63s system 838% cpu 33.947 total
Differential Revision: http://reviews.llvm.org/D19720
llvm-svn: 268037
If multiple find-all-symbols processes access the temporary directory
simultaneously with two files with the same name they would collide and
create a broken yaml file. Fix this by using the safe createUniqueFile
API from LLVM instead.
Differential Revision: http://reviews.llvm.org/D19717
llvm-svn: 268021
Summary:
The find-all-symbols tool generates a yaml symbol database for
include-fixer.
The symbol matcher is originally written by Xiaoyi Liu.
Reviewers: bkramer, djasper
Subscribers: cfe-commits, klimek, ioeric
Differential Revision: http://reviews.llvm.org/D19482
llvm-svn: 267719
Summary:
The goal of this tool is fairly simple, look up unknown identifiers in a
global database and add the corresponding #include line. It accomplishes
this by hooking into Sema as an ExternalSemaSource and responding to typo
correction callbacks. This means we can see the unknown identifier before
it's being munged by error recovery.
This doesn't work perfectly yet as some typo corrections don't emit
callbacks (delayed typos), but I think this is fixable. We also handle
only one include at a time as this is meant to be run directly from
the editing environment eventually. Adding multiple includes at the same
time is tricky because of error recovery.
This version only has a a dummy database, so all you can do is fixing
missing includes of <string>, but the indexer to build a database will
follow soon.
Reviewers: djasper
Subscribers: ioeric, hokein, cfe-commits
Differential Revision: http://reviews.llvm.org/D19314
llvm-svn: 266870
Eric Liu