error: unresolved name `a::b::c` [E0425] doesn't indicate which component doesn't exist

[Zoxc]

The unresolved name error message should indicate which path component it can't resolve.

For example:

../src/src/libstd\sys/common\unwind/mod.rs:148:27: 148:39 error: unresolved name `imp::payload` [E0425]
../src/src/libstd\sys/common\unwind/mod.rs:148         let mut payload = imp::payload();
                                                                         ^~~~~~~~~~~~

Here we are unable to tell if imp or payload doesn't resolve.

[GuillaumeGomez]

Hum, indeed. it's even more obvious with code like this:

mod a {}

fn main() {
    a::b::x;
}

However, it also precises that b wasn't found in a. What do you think of this @pnkfelix?

[pnkfelix]

Interesting that we have ended up with two distinct error codes (E0425 and E0433) that seem to indicate the same thing, as far as I can tell.

This probably arose because the ResolutionError enum has two variants, UnresolvedName and FailedToResolve, and it is not clear to me what the distinction between them is supposed to be. Maybe just a historical artifact?

I'd like to see if we could combine the two variants, and in the process, improve the error for E0425 in this case. (Combining the two variants would just be an internal improvement; it is probably not strictly necessary for resolving this issue.)

Note that both variants carry along a msg, which is how FailedToResolve is providing the extra info about "could not find b in a". So another good path of investigation would be to figure out how that msg is being plugged into FailedToResolve, and why the ResolutionError is only getting an empty string as its msg.

[GuillaumeGomez]

I'm gonna take a look (if you don't do it before me).

[TimNN]

I believe this has been fixed (cc #32789).

Edit: at least the example provided by GuillaumeGomez.

[GuillaumeGomez]

Great! I close it then.