Error on bad pub(path) depends on module ordering

[withoutboats]

Which error message you get with a non-ancestral pub(path) visibility restriction depends on the ordering of module declarations.

These two struct declarations produce different errors;

mod foo {
    pub(in ::bar) struct Foo;
}

mod bar {
    pub(in ::foo) struct Bar;
}

The second produces the correct error:

error: visibilities can only be restricted to ancestor modules

The first produces this, incorrect error:

error[E0578]: cannot find module `bar` in the crate root

Presumably the pub(path) code is operating on the assumption the path, if real, has already been walked (because any correct path would have been walked), but this is not the case.

[est31]

I've stumbled across this problem earlier today, see my dupe report above. It was my first attempt at using that feature, and I wasn't aware that only ancestor modules are allowed, and this issue added to the confusion.

[withoutboats]

This bug still exists. The syntax of path visibilities has changed to require in, but updating the code sample to pub(in ::foo) and pub(in ::bar), the error message is still order dependent.

[estebank]

@withoutboats: thanks for reviewing, I'll write mentoring instructions then.

[estebank]

Mentoring instructions:

Resolver::resolve_visibility() is the method responsible for raising visibility issues,
which calls Resolver::smart_resolve_path(), the method that raises E0578.

smart_resolve_path_fragment should be changed so it takes into consideration wether source is a PathSource::Visibility in report_errors so that instead of adding a UseError to use_injection (which are picked up by report_with_use_injections to suggest imports), we keep all the information needed to look for the (presumably) not yet seen mod and look for it after all checks have been performed (you probably would want to do it in report_errors). If you can find the mod, then raise an incorrect visibility restriction error, otherwise raise E0578 (You can keep around the original E0578 diagnostic and .cancel() it if you can find the mod afterwards, or emit it otherwise).

[jethrogb]

Bug still exists in 2018 edition but you have to write in crate::...

[estebank]

Triage: no change.

[petrochenkov]

#109657 is a duplicate of this issue and contains some explanation for the suboptimal diagnostics here.