ASTImporter tests may produce source file related warnings, the diagnostic
client should be in correct state to handle it. Added 'beginSourceFile' to set
the client state.
Details
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 18808 Build 18808: arc lint + arc unit
Event Timeline
It's not clear to me what kind of issue you are addressing, for example is the unit test hitting an assertion hit without your changes ? Or is there something else ?
Also it would be good to add some documentation comments to clarify what's the use case and when ASTUnit::beginSourceFile() should be getting called.
If BeginSourceFile is not called on the diagnostic client object, it is not possible to have compiler warnings or errors that come from the "To" context while importing something (there is assertion in TextDiagnosticPrinter::HandleDiagnostic). In the currently existing tests there is no such case but I have not yet committed tests that produce such warnings (for example ODR violations during import or encounter of unsupported constructs).
The new ASTUnit::beginSourceFile is only there to simplify the code. It is possible to get Ctx, PP and getDiagnostic() from outside of ASTUnit and call the same thing, but requires more code to write. Probably a more smart place to call BeginSourceFile can be found if we look deep into ASTUnit and buildAST functions that generate the AST from code that has associated source file but this would be a change that affects more code.
Thanks for the explanation. Please do add documentation comments for the new method so people using ASTUnit in their own code have an idea when and why they would need to call this. Something like "if you intend to emit additional diagnostics after the ASTUnit is created [...]".
Also consider making the naming more clear to match the intended purpose, like enableEmittingAdditionalDiagnostics() or something similar.
Otherwise LGTM.
- Added comment, renamed beginSourceFile, removed check for PP.
Check for PP is removed because it is allowed to be nullptr.
From API point of view if there is a enableSourceFileDiagnostics there should be a disableSourceFileDiagnostics too (that calls the EndSourceFile). But I am not sure how and if to use it at all. In the unit tests it is not needed, the ASTUnit contains a single entity for the "To" context.
We could leave disableSourceFileDiagnostics off until someone finds a use case for it.