Doing so removes the last reason to expose a FrontendAction from
libIndex.
Details
- Reviewers
ilya-biryukov jkorous
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 37429 Build 37428: arc lint + arc unit
Event Timeline
clang/lib/Index/IndexingAction.cpp | ||
---|---|---|
77 | The fact that we call addPPCallbacks after creating ASTContext is a bit concerning. This wouldn't probably cause any problems in practice, but generally changing preprocessor by the time ASTContext is already created seems dangerous (what if something there ever starts depending on the state of the preprocessor?) I think this concern is easily elevated if we change Preprocessor and call addPPCallbacks on CreateASTConsumer(CompilerInvocation& CI). That would mean we have a separate function that sets up the preprocessor and creates IndexASTConsumer and it should be exposed to the clients. Have you considered this approach? Would it work? |
clang/lib/Index/IndexingAction.cpp | ||
---|---|---|
77 | It does feel a bit weird, but we shouldn't have started parsing before calling Initialize on the ASTConsumer. Therefore I agree with you that it won't cause problems in practice. Calling addPPCallbacks in FrontendAction is against the goal of this patch set. The goal is to encapsulate as much as possible in the IndexASTConsumer, because they compose well, unlike FrontendActions. Therefore, requiring customization in FrontendAction is not possible. |
clang/lib/Index/IndexingAction.cpp | ||
---|---|---|
77 | We could also move the preprocessor setup to constructor and check/add asserts that ASTContext has been provided to IndexingContext and IndexDataConsumer implementations. |
LGTM
clang/lib/Index/IndexingAction.cpp | ||
---|---|---|
77 | LG, let's keep it like this and hope this won't break in the future too. std::unique_ptr<ASTConsumer> createIndexASTConsumer(CompilerInvocation &CI) { CI.getPreprocessor().addPPCallback(); return llvm::make_unique<IndexASTConsumer>(...); } That would reduce the gap between FrontendAction::BeginSourceFile and addPPCallbacks to just a few instructions, and the chances of breaking stuff would be even less. |
The fact that we call addPPCallbacks after creating ASTContext is a bit concerning.
This wouldn't probably cause any problems in practice, but generally changing preprocessor by the time ASTContext is already created seems dangerous (what if something there ever starts depending on the state of the preprocessor?)
I think this concern is easily elevated if we change Preprocessor and call addPPCallbacks on CreateASTConsumer(CompilerInvocation& CI). That would mean we have a separate function that sets up the preprocessor and creates IndexASTConsumer and it should be exposed to the clients.
Have you considered this approach? Would it work?