Give return-position impl traits in trait a (synthetic) name to avoid name collisions with new lowering strategy

[compiler-errors]

We were previously lowering RPITITs to associated items with the name "kw::Empty", which as petrochenkov predicted, causes name collisions when being decoded from foreign crates.

Instead, synthesize a name by concatenating the def-path segments of the original RPITIT, something like foo::{opaque#1} or foo::{opaque#0}::{opaque#0}. This should keep the item unnameable, since we never want to name it as that would be problematic as we lower these items after the resolver is run.

Also, fix a few unrelated bugs with nested RPITITs, and beefen up the foreign encoding test.

cc @petrochenkov and the test case described here: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/-Z.20lower-impl-trait-in-trait-to-assoc-ty.20summary.3F/near/343451927

[rustbot]

r? @Nilstrieb

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

[compiler-errors]

I guess there's no real reason why this needs to be a separate def path data. We could use TypeNs here now, (I guess) as long as we keep the actual name that the RPITIT is lowering to unnameable.

[spastorino]

Btw, it looks good to me but I'd leave this up to @petrochenkov given that they've self-assigned it.

[petrochenkov]

I think this is a big unnecessary complication.
See how macro_rules are ignored in build_reduced_graph_for_external_crate_res despite being in the children list.
Synthetic RPITITs can be ignored in the same way.

[petrochenkov]

It's kind of a philosophical question what exactly should go into the children list.

Right now only named items that are actually planted into modules and visible to other modules/crates in this way are put into the children list, that it's main use case.

Also macro_rules are put into the same list. Why? For historical reasons. They have to be ignored in the main user of children (build_reduced_graph_for_external_crate_res ) and could easily go into a separate list. I actually planned to remove them from this list, just never got to it.

Are synthetic RPITITs similar to macro_rules in this case?
Yes, they are not named and not planted into trait "modules ", so they either need to go to a separate list, or be ignored by the main user of the children list.
Something like that.

(I think I have a weak preference for separate lists for both after all.)

[spastorino]

I don't think this is really complicated, the meat of the change is 602cf24 and the change also help to make diagnostics be equal to master as seen in https://github.com/rust-lang/rust/pull/109455/files#diff-2245ba262b8ba2866c27f1ac3f76db96146870beb91a6ac7ce621ca2cbb7c501R9. Although I guess that could also be Trait::{opaque} instead of Trait::method::{opaque} and it would also be fine.

[bors]

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

[petrochenkov]

It's not very complicated, it's just unnecessarily complicated (I'm only talking about the last commit, others seem unrelated).
If these types don't have a name then they shouldn't have a name.
Then you also won't have to invent some hygiene emulation scheme to synthesize names (which currently breaks if two RPITITs are defined by the same method?).

[spastorino]

(which currently breaks if two RPITITs are defined by the same method?).

I don't think is going to break, you would end with Trait::method::{opaque#0}, Trait::method::{opaque#1} and so on.

Anyway, would leave this up to be answered by @compiler-errors

[spastorino]

Closing in favor of #109499