-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Silence some resolve errors when there have been glob import errors #125381
Conversation
if let ImportKind::Glob { .. } = import.kind { | ||
self.glob_error = true; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@petrochenkov I've tried injecting a nameless binding as a sentinel with things like the following here:
self.per_ns(|this, ns| {
this.define(import.parent_scope.module, Ident::with_dummy_span(kw::Empty), ns, this.dummy_binding);
});
but then I couldn't find those bindings back in smart_resolve_path_fragment
. I have access to the module and turn glob_error
into a FxHashSet<DefId>
that I check later before emitting the subsequent resolve errors, but that sounds like a bigger hack, inaccurate at that, effectively approximating normal resolve, so I'd like to figure out a way of injecting an unnameable binding as a sentinel so that the regular machinery does its thing, and the error silencing is always accurate (a bad use foo::*;
won't affect an unrelated scope).
This looks fine to me, but I want to cede review authority to petrochenkov who already self-assigned. |
Could not assign reviewer from: |
I'm surprised how little effect this had on the test suite. |
It now uses
I believe that the only situation where this is a problem is during changes to existing codebases, which is a case that is not well represented in our test suite. @rustbot review |
r=me with minor cleanup (#125381 (comment)). |
When encountering `use foo::*;` where `foo` fails to be found, and we later encounter resolution errors, we silence those later errors. A single case of the above, for an *existing* import on a big codebase would otherwise have a huge number of knock-down spurious errors. Ideally, instead of a global flag to silence all subsequent resolve errors, we'd want to introduce an unameable binding in the appropriate rib as a sentinel when there's a failed glob import, so when we encounter a resolve error we can search for that sentinel and if found, and only then, silence that error. The current approach is just a quick proof of concept to iterate over. Partially address rust-lang#96799.
@bors r+ |
Silence some resolve errors when there have been glob import errors When encountering `use foo::*;` where `foo` fails to be found, and we later encounter resolution errors, we silence those later errors. A single case of the above, for an *existing* import on a big codebase would otherwise have a huge number of knock-down spurious errors. Ideally, instead of a global flag to silence all subsequent resolve errors, we'd want to introduce an unnameable binding in the appropriate rib as a sentinel when there's a failed glob import, so when we encounter a resolve error we can search for that sentinel and if found, and only then, silence that error. The current approach is just a quick proof of concept to iterate over. Partially address rust-lang#96799.
Rollup of 8 pull requests Successful merges: - rust-lang#124251 (Add an intrinsic for `ptr::metadata`) - rust-lang#124320 (Add `--print=check-cfg` to get the expected configs) - rust-lang#125226 (Make more of the test suite run on Mac Catalyst) - rust-lang#125381 (Silence some resolve errors when there have been glob import errors) - rust-lang#125633 (miri: avoid making a full copy of all new allocations) - rust-lang#125638 (Rewrite `lto-smoke`, `simple-rlib` and `mixing-deps` `run-make` tests in `rmake.rs` format) - rust-lang#125639 (Support `./x doc run-make-support --open`) - rust-lang#125664 (Tweak relations to no longer rely on `TypeTrace`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 8 pull requests Successful merges: - rust-lang#124251 (Add an intrinsic for `ptr::metadata`) - rust-lang#124320 (Add `--print=check-cfg` to get the expected configs) - rust-lang#125226 (Make more of the test suite run on Mac Catalyst) - rust-lang#125381 (Silence some resolve errors when there have been glob import errors) - rust-lang#125633 (miri: avoid making a full copy of all new allocations) - rust-lang#125638 (Rewrite `lto-smoke`, `simple-rlib` and `mixing-deps` `run-make` tests in `rmake.rs` format) - rust-lang#125639 (Support `./x doc run-make-support --open`) - rust-lang#125664 (Tweak relations to no longer rely on `TypeTrace`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#125381 - estebank:issue-96799, r=petrochenkov Silence some resolve errors when there have been glob import errors When encountering `use foo::*;` where `foo` fails to be found, and we later encounter resolution errors, we silence those later errors. A single case of the above, for an *existing* import on a big codebase would otherwise have a huge number of knock-down spurious errors. Ideally, instead of a global flag to silence all subsequent resolve errors, we'd want to introduce an unnameable binding in the appropriate rib as a sentinel when there's a failed glob import, so when we encounter a resolve error we can search for that sentinel and if found, and only then, silence that error. The current approach is just a quick proof of concept to iterate over. Partially address rust-lang#96799.
When encountering
use foo::*;
wherefoo
fails to be found, and we later encounter resolution errors, we silence those later errors.A single case of the above, for an existing import on a big codebase would otherwise have a huge number of knock-down spurious errors.
Ideally, instead of a global flag to silence all subsequent resolve errors, we'd want to introduce an unnameable binding in the appropriate rib as a sentinel when there's a failed glob import, so when we encounter a resolve error we can search for that sentinel and if found, and only then, silence that error. The current approach is just a quick proof of concept to iterate over.
Partially address #96799.