Say that pub(in path) can't depend on use statements

[mattheww]

Arbitrary path expressions aren't allowed here (in particular, the path can't rely on another use statement).

[mattheww]

Sorry, saying "canonical path" isn't right because things like pub (in super::m) are allowed.

So instead, just say explicitly that using names from use statements isn't allowed.

[traviscross]

@petrochenkov: We talked about this in the lang-docs call today, and we were uncertain whether or not this behavior is intentional, or what the history is here. What do you think?

This is about cases like this:

mod m {
    use crate::m as n;
    pub(in self::n) fn f() {}
    //~^ ERROR failed to resolve: could not find `n` in `self`
}

[Edit: Thanks to @mattheww for a fix to this example.]

[petrochenkov]

I explained the situation in rust-lang/rust#109657 (comment).

Basically supporting arbitrary paths in pub is both nontrivial and has very little value, so it's easier to say that only parent paths without imports are supported.

I suspect that in practice imports may be supported in some cases, if they are ready early enough, but it's not guaranteed.

[petrochenkov]

Example of pub(in path) resolved through an import:

mod a {
    macro_rules! delay {
        () => { pub(in crate::b) struct S; }
    }
    
    delay!();
}
use a as b;

I wouldn't want to guarantee that this ^^^ works.

[traviscross]

Thanks @petrochenkov for that background. Wild example there; thanks for sharing that.

Given that, the change seems fine. Thanks @mattheww.