privacy: Fix type privacy holes when it doesn't cause too much breakage#152543
privacy: Fix type privacy holes when it doesn't cause too much breakage#152543petrochenkov wants to merge 1 commit intorust-lang:mainfrom
Conversation
|
@bors try |
privacy: Fix type privacy holes when it doesn't cause too much breakage
This comment has been minimized.
This comment has been minimized.
|
TODO: |
|
r? @fmease rustbot has assigned @fmease. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
Footnotes
|
|
Crater results are basically the same as #146470 without the second commit (see e.g. #146470 (comment)). |
|
Previous FCP - #146470 (comment). |
|
We talked about this in the lang call last week. @petrochenkov, it'd be helpful to us to have a brief write-up of what's being proposed here and what's changed since our FCP in #146470 (comment). |
Nothing is changed since the FCP in #146470 (comment). |
|
The previous summary (#146470 (comment)) is still relevant, except user-written private bounds on associated types are not turned into an error due to the amount breakage. pub trait PubTrait {
fn foo1() -> impl PrivTrait; // error now
fn foo2() -> impl PubTrait<PrivType>; // error now
type A1: PrivTrait; // not error, too much breakage (but reports `private_bounds` lint)
type A2: PubTrait<PrivType>; // not error, too much breakage (but reports `private_bounds` lint)
} |
A subset of #146470.
Private types in RPITITs now report hard errors.
Private types in bounds of associated types still only report the
private_boundslint due to unacceptable amount of breakage (#146470 (comment)).Closes #144139