(re-)Fix private-in-public for RPITIT

[compiler-errors]

#143357 fixed a latent bug where we weren't detecting private-in-public errors for RPITITs. In order to not break any existing code, @cjgillot temporarily reenabled the previous behavior in #144098.

This issue tracks the crater run to determine if that change had any real-world fallout. Ideally we fix the fallout and re-enable the intended behavior, which is to actually detect private-in-public errors in RPITITs just like RPITs and normal associated items. I'm opening an issue just to make sure the crater run doesn't get forgotten on a closed PR. I probably should've started the crater run here, but oh well! :^)

cc @cjgillot @petrochenkov

---

You can check out the queue and this experiment's details.

Originally posted by @craterbot in #144098 (comment)

[mladedav]

(The playground links might have different behavior once #144098 is merged.)

Ideally we fix the fallout and re-enable the intended behavior, which is to actually detect private-in-public errors in RPITITs just like RPITs and normal associated items.

Both private traits in RPITs and associated types are not hard errors either and the change triggers errors only for RPITIT with provided methods, not for required methods.

So I just really want to make sure we're all talking about the same thing here. Should all of the methods and the associated type in this playground be hard errors?

Also, RFC 2145 makes it sound like these should not ideally be errors either, it was just a technical limitation but it seems that everything is linted correctly now so in that spirit these should be just warn-by-default lints, no?

---

Sorry if I sound like a broken record, I just don't understand why that single case (provided method RPITIT) should be treated as an error while the description here makes it sound like the change is aligning behavior.

[compiler-errors]

Sorry for the confusion @mladedav -- I guess I should've written "lint" rather than "error".

My understanding is that these should be warnings at least, and possibly errors. As far as I can tell, that PR changed RPITITs from no warning or error into warnings and errors, depending on the presence of a default body (afaict) -- new hard errors are pretty bad, but new lints probably shouldn't be extended either without at least understanding them and confirming they're desirable 🤔

@petrochenkov may have a better idea about which of these should be errors or warnings, and generally the direction of priv-in-pub.

I just opened this issue to ensure we don't forget to make some change, since the PR that I approved is a bit of a hack.

[petrochenkov]

which of these should be errors or warnings

Everything in associated types - errors, otherwise - lints.

The technical limitations the RFC is talking about are still in place.
The full normalization (#126076) may help with this, or may not, I don't quite remember.

[mladedav]

Thank you both for the clarifications. So everything in the playground really should be an error then, if I understand it correctly.