🍒[lldb][ClangModulesDeclVendor] Cherry-pick Clang modules error handling refactor #11781
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(cherry picked from commit bda7289)
…ng modules (llvm#166917) Instead of propagating the errors as a `bool`+`Stream` we change the `ClangModulesDeclVendor` module loading APIs to use `llvm::Error`. We also reword some of the diagnostics (notably removing the hardcoded `error:` prefix). A follow-up patch will further make the module loading errors less noisy. See the new tests for what the errors look like. rdar://164002569 (cherry picked from commit 7f55f26)
… individual import failed (llvm#166940) Depends on: * llvm#166917 When loading all Clang modules for a CU, we stop on first error. This means benign module loading errors may stop us from importing actually useful modules. There's no good reason to bail on the first one. The pathological case would be if we try to load a large number of Clang modules but all fail to load for the same reason. That could happen, but in practice I've always seen only a handful of modules failing to load out of a large number. Particularly system modules are useful and usually don't fail to load. Whereas project-specific Clang modules are more likely to fail because the build system moves the modulemap/sources around. This patch accumulates all module loading errors and doesn't stop when an error is encountered. (cherry picked from commit 74e34ef)
…xpression log instead of console (llvm#166964) Depends on: * llvm#166917 * llvm#166940 While these errors can contribute to an expression failing, they are never *the* reason the expression failed. I.e., they are always just 'note:' diagnostics that we hand-emit. Because they are quite noisy (and we potentially have many of them if we auto-load all modules in a CU), this patch logs the errors to the `expr` log, instead of the console. Previously these errors would only get omitted when the expression itself failed. Meaning if the expression failed, we'd dump these 'note' module load errors in next to the actual expression error, obscuring the output. Moreover, if the expression succeeded, any module load errors would be dropped. Now we always log all module loading errors to the expression log, regardless of whether the expression fails or not. (cherry picked from commit d5b62fa)
Author
|
@swift-ci teset |
Author
|
@swift-ci test |
Author
|
@swift-ci test Windows |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
rdar://164002569