-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Resolve failure with multiple reexports #18083
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
Labels
A-resolve
Area: Name/path resolution done by `rustc_resolve` specifically
Comments
Closed
traige: this is still true |
elinorbgr
added a commit
to elinorbgr/rust
that referenced
this issue
Jun 28, 2015
When encountering an indeterminate import, still try to resolve the following imports of the module. This avoids dead-lock-like situations where 2 modules are blocked, each waiting for the resolution of the other. Fixes rust-lang#18083.
elinorbgr
added a commit
to elinorbgr/rust
that referenced
this issue
Jul 31, 2015
Most errors generated by resolve might be caused by not-yet-resolved glob imports. This changes the behavior of the resolve imports algorithms to not fail prematurally on first error, but instead buffer intermediate errors and report them only when stuck. Fixes rust-lang#18083
bors
added a commit
that referenced
this issue
Aug 5, 2015
(This is a second try at #26242. This time I think things should be ok.) The current algorithm handling import resolutions works sequentially, handling imports in the order they appear in the source file, and blocking/bailing on the first one generating an error/being unresolved. This can lead to situations where the order of the `use` statements can make the difference between "this code compiles" and "this code fails on an unresolved import" (see #18083 for example). This is especially true when considering glob imports. This PR changes the behaviour of the algorithm to instead try to resolve all imports in a module. If one fails, it is recorded and the next one is tried (instead of directly giving up). Also, all errors generated are stored (and not reported directly). The main loop of the algorithms guaranties that the algorithm will always finish: if a round of resolution does not resolve anything new, we are stuck and give up. At this point, the new version of the algorithm will display all errors generated by the last round of resolve. This way we are sure to not silence relevant errors or help messages, but also to not give up too early. **As a consequence, the import resolution becomes independent of the order in which the `use` statements are written in the source files.** I personally don't see any situations where this could be a problem, but this might need some thought. I passed `rpass` and `cfail` tests on my computer, and now am compiling a full stage2 compiler to ensure the crates reporting errors in my previous attempts still build correctly. I guess once I have checked it, this will need a crater run? Fixes #18083. r? @alexcrichton , cc @nrc @brson
lnicola
pushed a commit
to lnicola/rust
that referenced
this issue
Sep 25, 2024
…k, r=Veykril Skip checks for cast to dyn traits It seems that chalk fails to solve some obvious goals when there are some recursiveness in trait environments. And it doesn't support trait upcasting yet. rust-lang/chalk#796 This PR just skips for casting into types containing `dyn Trait` to prevent false positive diagnostics like rust-lang#18047 and rust-lang#18083
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If either of the
use
statements are removed or apub use
is moved above theuse
, everything builds. It looks like resolve is failing to resolveb::B
anda::A
in the first round (as it should), but then gives up on the whole module, which prevents the reexport from being processed.The text was updated successfully, but these errors were encountered: