resolve: Improve import failure detection and lay groundwork for RFC 1422

[jseyfried]

This PR improves import failure detection and lays some groundwork for RFC 1422.
More specifically, it

• Avoids recomputing the resolution of an import directive's module path.
• Refactors code in resolve_imports that does not scale to the arbitrarily many levels of visibility that will be required by RFC 1422.
  • Replaces ModuleS's fields public_glob_count, private_glob_count, and resolved_globs with a list of glob import directives globs.
  • Replaces NameResolution's fields pub_outstanding_references and outstanding_references with a field single_imports of a newly defined type SingleImports.
• Improves import failure detection by detecting cycles that include single imports (currently, only cycles of globs are detected). This fixesImprove name resolution failure detection #32119.

r? @nikomatsakis

[jseyfried]

After this PR, the first coherence condition from this comment will hold.

[jseyfried]

The improved failure detection subsumes this hack.

[jseyfried]

cc @petrochenkov@nrc

[bors]

☔ The latest upstream changes (presumably #32167) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

(note: starting reviewing, didn't yet finish)

[nikomatsakis]

I don't quite follow this -- why are you checking if source == target? Can you maybe give an example of some Rust code that would trigger this path?

[nikomatsakis]

looks good, though I'd like to learn the answer to my question :)

r=me with an extended comment

[jseyfried]

I improved the design in the above commit so that the source == target check is no longer needed.

The check was needed since this code assumed that there was a cycle when we try to resolve a name in a module that is already borrowed (i.e. in which we are already trying to resolve a name). If we only follow globs and non-renamed single imports, this assumption is correct since the names are guaranteed to be the same. If we followed renamed single imports,

structBar;use foo::Baz;//^ here, we would try to resolve `foo::Baz`. Since `foo::Baz` is not yet successful,//| we would follow the only single import that can define it (`use self::Bar as Baz`) and//| try to resolve `foo::Bar`, which would incorrectly fail since `foo` is already borrowed//| (causing the above import to incorrectly fail).mod foo {useself::BarasBaz;useBar;}

The above commit borrows the NameResolution directly when resolving a name (instead of borrowing its containing module) so that there are no "false positive" cycles even when following renamed single imports.
Following renamed single imports is necessary for the amended test to pass since otherwise we could not conclude that pub use super::T as S; fails in the value namespace.

[nikomatsakis]

@jseyfried

I was always suspicious of that logic around cycle detection, makes sense.

@bors r+

[bors]

📌 Commit 6f09dea has been approved by nikomatsakis

[bors]

⌛ Testing commit 6f09dea with merge 3562671...

[alexcrichton]

@bors: retry force clean

[bors]

⌛ Testing commit 6f09dea with merge 7fd331e...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-64-x-armhf, auto-linux-64-x-armsf, auto-linux-64-x-freebsd, auto-linux-64-x-netbsd, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild