On privacy error caused by private reexport, use spans to show the use chain

[estebank]

Fix #63942, fix #57619. Partially address #42909.

[rust-highfive]

r? @zackmdavis

(rust_highfive has picked a reviewer for you, use r? to override)

[estebank]

@petrochenkov would you have some advice on how to get a better suited source for a usable path string in resolve?

[petrochenkov]

There are zero guarantees that a direct path won't have private segments, especially given that module structures with facades are pretty popular.
So trying to guess and use full paths here means inviting false positives.

I'd rather keep the status quo and say only the name.
(In this case the changes in src/librustc/hir/map/definitions.rs can be removed as well, those strings are not user-facing otherwise and are used only for debugging.)

[estebank]

@petrochenkov would you have some advice on how to properly check the visibility of a given ADT here? I'm guessing I would have to ferry some scope information in PrivacyError.

[petrochenkov]

This issue doesn't apply to the simpler version of this PR (#67951 (comment)) which I'd like to see implemented first.
I'm not sure we'll need anything beyond that.

[varkor]

I really like these more informative errors! They could just do with a little tweaking for readability.

[petrochenkov]

r? @petrochenkov

[petrochenkov]

I'm not sure that reporting the full reexports chains is useful.
The important thing to report here is that the import we are trying to access is private.

So, I'd replace this:

error[E0603]: module `bar` is private
  --> $DIR/shadowed-use-visibility.rs:9:14
   |
LL |     use foo::bar::f as g;
   |              ^^^ this module is private
   |
note: used restricted re-export of `bar`
  --> $DIR/shadowed-use-visibility.rs:4:9
   |
LL |     use foo as bar;
   |         ^^^^^^^^^^
note: re-exported module `bar` is declared here
  --> $DIR/shadowed-use-visibility.rs:1:1
   |
LL | / mod foo {
LL | |     pub fn f() {}
LL | |
LL | |     use foo as bar;
LL | |     pub use self::f as bar;
LL | | }
   | |_^

with this

error[E0603]: module import `bar` is private
  --> $DIR/shadowed-use-visibility.rs:9:14
   |
LL |     use foo::bar::f as g;
   |              ^^^ this import is private
   |
note: the module import `bar` is declared here
  --> $DIR/shadowed-use-visibility.rs:4:9
   |
LL |     use foo as bar;
   |         ^^^^^^^^^^

This would be a pretty minimal change to the code existing on master.
This PR is trying to be too smart an do too much in a single step, so it's hard to see what is essential and what can be removed to keep the code simple.

[estebank]

The important thing to report here is that the import we are trying to access is private.

The concern I have is that by only stating "you're importing something private, and this is the private re-export" and nothing else we don't give users a chance of changing their use statement. By pointing the whole chain of re-exports all the way to the original definition, we might be giving a lot of unnecessary information, but we're giving the user a good idea of whether they want to import the original struct directly, or one of the public reexports. An option would be to only show the chain of public re-export and hide the private ones, but that "inconsistency" on what we show could be confusing.

[petrochenkov]

I'd still want to see the diff between the basic version and what this PR does, so I made #68153.

[petrochenkov]

Blocked on #68153 and #67951 (comment).

[Dylan-DPC-zz]

@estebank this is unblocked now

[estebank]

@Dylan-DPC thanks for the ping.

@petrochenkov rebased and squashed on top of latest master, the diff is much smaller now.

[estebank]

I think this clarification in particular will be incredibly useful when trying to understand these errors.

[petrochenkov]

I will get to this next weekend.

[petrochenkov]

I'll close this in favor of #69811 which does roughly the same thing.