tests: add private RPITIT & exported_private_dependencies tests

[mladedav]

Private RPITIT used to not be linted (#143531), but it became linted and in some cases a hard error in #143357.

This PR just adds tests so that this behavior does not go away though there is work to be done:

• required methods lint only private_bounds, but provided methods also output E0446.
• private dependency in public interface is linted twice for provided methods (and just once for required methods).
• it points to {annon_assoc#0} instead of the method itself

[rustbot]

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[mladedav]

I converted this to a draft since I noticed that one of the errors is not a lint but a hard error, which I believe to be a mistake. So I think it would be better to figure that one out first and then pick this up again.

@rustbot label +S-waiting-on-author -S-waiting-on-review

[cjgillot]

@compiler-errors @petrochenkov the "bugfix" is accidental. As this causes a hard error, should we issue a warkaround to remove the error with a future-compat lint?

[compiler-errors]

We could crater this to see the extent of the error, and T-lang nominate it with the suggestion that if the fallout is small or nonexistent then we could just make it a hard error directly?

[mladedav]

I don't think this should produce a hard error. It doesn't error for RPIT outside traits, for required functions with RPITIT or provided functions with concrete private type.

It might not have been clear from the changes to the tests here, but the merged PR made some lints work regarding private types in interface (which is great), but I don't think the new hard error should apply here.

The error specifically talks only about associated types so it could be confusing to users as it seems to accidentally check the generated associated types which is just a compiler implementation detail and the message would probably be confusing to users. So if this is in fact desirable, it should probably have the message changed and it should be consistent with required functions in traits.

Playground

[bors]

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