This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Refactoring of GlobalCompilationDatabase
Needs ReviewPublic

Authored by sammccall on Nov 24 2017, 3:46 PM.

Details

Reviewers
ilya-biryukov
Summary

The interface used is now tooling::CompilationDatabase.
The various behaviors of the existing CDB implementation is decomposed into
several classes responsible for one aspect each.

  • The fallback commands are now a FixedCompilationDatabase. For now, this is done by both ClangdLSPServer and ClangdServer (preserving behavior) but I'd like to eliminate the latter, as embedders of ClangdServer are in a better position to know what fallback is appropriate.
  • the fallback now uses '.' as the directory, rather than the file's parent.
  • The compilation database file scan caches missing as well as present files.
  • -fsyntax-only is now applied to all commands, not just the fallback. We also string output flags.
  • The final command line used for each file is now logged.
  • The -resource-dir flag is managed by ClangdServer rather than being done deeper in the stack. All flag manipulation is done by CDBs set up by ClangdLSPServer and ClangdServer.
  • Race in extra-flags fixed: when reading extra flags for a file we now lock the map

Event Timeline

sammccall created this revision.Nov 24 2017, 3:46 PM
sammccall edited the summary of this revision. (Show Details)Nov 24 2017, 3:50 PM
ilya-biryukov added inline comments.Nov 27 2017, 2:18 AM
clangd/ClangdLSPServer.cpp
254

Clangd still changes working directory when running the parsing, so "." might end up being a different dir on multiple runs over the same file.
Maybe use file's parent for now?

clangd/ClangdServer.cpp
178

Maybe move this code out of ClangdServer? Arguably, it should be less confusing for clients of ClangdServer if they get exactly the compile commands returned by CDB.

This would also allow to get rid of ResourceDir parameter, which seems to be handled by CompilationDatabase now.

clangd/ClangdServer.h
208

Are there any mutating methods in CompilataionDatabase? Why do we use const & instead of &?

clangd/GlobalCompilationDatabase.cpp
57

IIRC, Cmd could come directly from compile_commands.json.
We should avoid crashing clangd if contents of compile_commands.json are invalid. Could we log the error instead and continue with other commands instead?

clangd/GlobalCompilationDatabase.h
34

It seems that this const means more trouble for implementations (i.e. using mutable, etc.) without providing any value.
Maybe we should consider removing it from the interface?
Am I missing the upsides of using const here?

61

Maybe we should consider using non-owning reference here?
It gives more flexibility, e.g. allowing to allocate on stack or store CDB directly inside the class fields, albeit it requires a bit more code to setup.
I'd say upsides of non-owning semantics outweigh a bit of added complexity

malaperle added a subscriber: malaperle.

@Nebiroth , Will this be compatible with your patch to change CompilationDatabase at runtime? https://reviews.llvm.org/D39571