Skip to content

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

Closed
sfackler opened this issue Oct 16, 2014 · 2 comments · Fixed by #27439
Closed

Resolve failure with multiple reexports #18083

sfackler opened this issue Oct 16, 2014 · 2 comments · Fixed by #27439
Labels
A-resolve Area: Name/path resolution done by `rustc_resolve` specifically

Comments

@sfackler
Copy link
Member

mod a {
    use b::{B};
    pub use self::inner::A;

    mod inner {
        pub struct A;
    }
}

mod b {
    use a::{A};
    pub use self::inner::B;

    mod inner {
        pub struct B;
    }
}

fn main() {}
<anon>:11:13: 11:14 error: unresolved import (maybe you meant `A::*`?)
<anon>:11     use a::{A};
                      ^
<anon>:2:13: 2:14 error: unresolved import (maybe you meant `B::*`?)
<anon>:2     use b::{B};
                     ^

If either of the use statements are removed or a pub use is moved above the use, everything builds. It looks like resolve is failing to resolve b::B and a::A in the first round (as it should), but then gives up on the whole module, which prevents the reexport from being processed.

@sfackler
Copy link
Member Author

cc @nikomatsakis

@sfackler sfackler added the A-resolve Area: Name/path resolution done by `rustc_resolve` specifically label Oct 16, 2014
@steveklabnik
Copy link
Member

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
Labels
A-resolve Area: Name/path resolution done by `rustc_resolve` specifically
Projects
None yet
2 participants