[PATCH] D75665: [analyzer] On-demand parsing capability for CTU
Gábor Horváth via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Apr 20 05:20:48 PDT 2020
xazax.hun added inline comments.
================
Comment at: clang/include/clang/CrossTU/CrossTranslationUnit.h:56
+ load_threshold_reached,
+ ambiguous_compile_commands_database
};
----------------
The two enum values refer to compilation database and compile command database. I'd prefer to use the same wording in both values.
================
Comment at: clang/include/clang/CrossTU/CrossTranslationUnit.h:227
+ /// Identifier.
+ virtual LoadResultTy load(StringRef Identifier) = 0;
+ virtual ~ASTLoader() = default;
----------------
I am not sure if this is good design.
Here, if the meaning of the `Identifier` depends on the subclass, the caller of this method always needs to be aware of the dynamic type of the object. What is the point of a common base class if we always need to know the dynamic type?
Looking at the code this does not look bad. But it might be a code smell.
================
Comment at: clang/include/clang/CrossTU/CrossTranslationUnit.h:285
public:
- ASTUnitStorage(const CompilerInstance &CI);
+ ASTUnitStorage(CompilerInstance &CI);
/// Loads an ASTUnit for a function.
----------------
Why is this no longer const?
================
Comment at: clang/lib/CrossTU/CrossTranslationUnit.cpp:120
+ case index_error_code::ambiguous_compile_commands_database:
+ return "Compile commands database contains multiple references to the "
+ "same source file.";
----------------
Unfortunately, this is a very common case for a large number of projects that supports multiple targets (e.g. 32 and 64 bits). Is there a plan to mitigate this problem?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D75665/new/
https://reviews.llvm.org/D75665
More information about the cfe-commits
mailing list