Use impl restrictions in std, core#157170
Conversation
This comment has been minimized.
This comment has been minimized.
| /// Trait to determine if a descriptor/handle refers to a terminal/tty. | ||
| #[stable(feature = "is_terminal", since = "1.70.0")] | ||
| pub trait IsTerminal: crate::sealed::Sealed { | ||
| pub impl(crate) trait IsTerminal { |
There was a problem hiding this comment.
Don't we want to block this PR on rustdoc support?
IsTerminal is stable and AFAICT the docs don't mention anywhere that the trait is sealed, so if we were to merge your PR now, users would no longer know that the trait is sealed just by looking at the docs. That feels unfortunate.
There was a problem hiding this comment.
I'm not opposed to blocking it on such. I deliberately left any "this trait is sealed" comments for that reason. Once there's rustdoc support, all of those can be removed as well.
There was a problem hiding this comment.
I don't think we need to wait for rustdoc as long as it's clear that the trait is sealed in the docs. We might have a rustdoc implementation soon enough1 (EDIT: #157310).
I could also see a middleground and have both the Sealed trait and impl(..) restrictions.
Let's nominate it for T-libs to decide.
Footnotes
There was a problem hiding this comment.
We could temporarily add doc comments to each relevant trait.
a6278c5 to
4bdbe8a
Compare
This comment has been minimized.
This comment has been minimized.
4bdbe8a to
ce88386
Compare
|
CI will certainly fail again. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
ce88386 to
478acf6
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
This comment has been minimized.
This comment has been minimized.
|
CI is now passing. |
|
T-libs was +1 in the meeting and no objections to doing this were raised. Let's go. @bors r+ |
|
📋 This PR cannot be approved because it currently has the following label: |
|
@bors r+ |
Rollup of 12 pull requests Successful merges: - #157085 (powerpc: warn against incorrect values for ABI-relevant target features) - #157170 (Use `impl` restrictions in `std`, `core`) - #157217 ([tiny] remove unecessary `.into()` calls) - #157262 (rustdoc: IXCRE: Preserve sizedness bounds on type params belonging to the parent item) - #157379 (Some more simple per-owner resolver changes) - #157381 (librustdoc: fix CSS border issue to support Firefox high contrast mode) - #155512 (interpreter: improve comments and error message in mir_assign_valid_types) - #157254 (Correct description of panic.rs) - #157290 (interpret: fix mir::UnOp layout computation) - #157332 (Rewrite target checking for `#[sanitize]`) - #157351 (Avoid leaking the query-job collection warning into the panic query stack) - #157389 (Add @clarfonthey to libs review rotation)
Rollup of 12 pull requests Successful merges: - rust-lang/rust#157085 (powerpc: warn against incorrect values for ABI-relevant target features) - rust-lang/rust#157170 (Use `impl` restrictions in `std`, `core`) - rust-lang/rust#157217 ([tiny] remove unecessary `.into()` calls) - rust-lang/rust#157262 (rustdoc: IXCRE: Preserve sizedness bounds on type params belonging to the parent item) - rust-lang/rust#157379 (Some more simple per-owner resolver changes) - rust-lang/rust#157381 (librustdoc: fix CSS border issue to support Firefox high contrast mode) - rust-lang/rust#155512 (interpreter: improve comments and error message in mir_assign_valid_types) - rust-lang/rust#157254 (Correct description of panic.rs) - rust-lang/rust#157290 (interpret: fix mir::UnOp layout computation) - rust-lang/rust#157332 (Rewrite target checking for `#[sanitize]`) - rust-lang/rust#157351 (Avoid leaking the query-job collection warning into the panic query stack) - rust-lang/rust#157389 (Add @clarfonthey to libs review rotation)
This should all be quite self-explanatory. I've used the tightest module permitted by current implementation, which is overwhelmingly
selfas I had expected.r? @Urgau