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
Benjamin Kramer