Speculative crate loading is not speculative enough #55103
Assignees
Labels
A-metadata
Area: Crate metadata
C-bug
Category: This is a bug.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
petrochenkov
added
A-metadata
|
Fixed in #74071. |
rust-timer
added a commit
to rust-timer/rust
that referenced
this issue
Jul 21, 2020
Original message: Rollup merge of rust-lang#74071 - petrochenkov:cload3, r=matthewjasper rustc_metadata: Make crate loading fully speculative Instead of reporting `span_err`s on the spot crate loading errors are now wrapped into the `CrateError` enum and returned, so they are reported only at the top level `resolve_crate` call, and not reported at all if we are resolving speculatively with `maybe_resolve_crate`. As a result we can attempt loading crates for error recovery (e.g. import suggestions) without any risk of producing extra errors. Also, this means better separation between error reporting and actual logic. Fixes rust-lang#55103 Fixes rust-lang#56590
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Speculative crate loading is performed as a part of speculative name resolutions (
fn maybe_process_path_extern) which is used for various import suggestions, lints and similar things.It's supposed to be silent and return
Noneif the crate cannot be loaded, however it still reports an error if the crate path doesn't exist.This shouldn't happen and crate path errors should be delayed until we know whether the crate loading is speculative or not.
After this issue is fixed, the test change in #55102 needs to be reverted.
cc @davidtwco @eddyb
The text was updated successfully, but these errors were encountered: