Rollup of 7 pull requests #92329
Merged
Rollup of 7 pull requests #92329
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In `Vec`, two doc tests are using `MaybeUninit::write` , stabilized in 1.55. This makes docs' usage of `maybe_uninit_extra` feature unnecessary.
…ochenkov Relax priv-in-pub lint on generic bounds and where clauses of trait impls. The priv-in-pub lint is a legacy mechanism of the compiler, supplanted by a reachability-based [type privacy](https://github.com/rust-lang/rfcs/blob/master/text/2145-type-privacy.md) analysis. This PR does **not** relax type privacy; it only relaxes the lint (as proposed by the type privacy RFC) in the case of trait impls. ## Current Behavior On public trait impls, it's currently an **error** to have a `where` bound constraining a private type with a trait: ```rust pub trait Trait {} pub struct Type {} struct Priv {} impl Trait for Priv {} impl Trait for Type where Priv: Trait // ERROR {} ``` ...and it's a **warning** to have have a public type constrained by a private trait: ```rust pub trait Trait {} pub struct Type {} pub struct Pub {} trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // WARNING {} ``` This lint applies to `where` clauses in other contexts, too; e.g. on free functions: ```rust struct Priv<T>(T); pub trait Pub {} impl<T: Pub> Pub for Priv<T> {} pub fn function<T>() where Priv<T>: Pub // WARNING {} ``` **These constraints could be relaxed without issue.** ## New Behavior This lint is relaxed for `where` clauses on trait impls, such that it's okay to have a `where` bound constraining a private type with a trait: ```rust pub trait Trait {} pub struct Type {} struct Priv {} impl Trait for Priv {} impl Trait for Type where Priv: Trait // OK {} ``` ...and it's okay to have a public type constrained by a private trait: ```rust pub trait Trait {} pub struct Type {} pub struct Pub {} trait Priv {} impl Priv for Pub {} impl Trait for Type where Pub: Priv // OK {} ``` ## Rationale While the priv-in-pub lint is not essential for soundness, it *can* help programmers avoid pitfalls that would make their libraries difficult to use by others. For instance, such a lint *is* useful for free functions; e.g. if a downstream crate tries to call the `function` in the previous snippet in a generic context: ```rust fn callsite<T>() where Priv<T>: Pub // ERROR: omitting this bound is a compile error, but including it is too { function::<T>() } ``` ...it cannot do so without repeating `function`'s `where` bound, which we cannot do because `Priv` is out-of-scope. A lint for this case is arguably helpful. However, this same reasoning **doesn't** hold for trait impls. To call an unconstrained method on a public trait impl with private bounds, you don't need to forward those private bounds, you can forward the public trait: ```rust mod upstream { pub trait Trait { fn method(&self) {} } pub struct Type<T>(T); pub struct Pub<T>(T); trait Priv {} impl<T: Priv> Priv for Pub<T> {} impl<T> Trait for Type<T> where Pub<T>: Priv // WARNING {} } mod downstream { use super::upstream::*; fn function<T>(value: Type<T>) where Type<T>: Trait // <- no private deets! { value.method(); } } ``` **This PR only eliminates the lint on trait impls.** It leaves it intact for all other contexts, including trait definitions, inherent impls, and function definitions. It doesn't need to exist in those cases either, but I figured I'd first target a case where it's mostly pointless. ## Other Notes - See discussion [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/relax.20priv-in-pub.20lint.20for.20trait.20impl.20.60where.60.20bounds/near/222458397). - This PR effectively reverts rust-lang#79291.
Fix the error of checking `base_expr` twice in type_changing_struct_update Fixes rust-lang#92010
…acro-asm, r=cjgillot rustc_builtin_macros: make asm mod public for rustfmt Follow up to rust-lang#92016, as I'd completely missed that the mod we needed was internal
resolve: Minor miscellaneous cleanups from rust-lang#89059 `@bors` rollup=always
Remove `maybe_uninit_extra` feature from Vec docs In `Vec`, two doc tests are using `MaybeUninit::write` , stabilized in 1.55. This makes docs' usage of `maybe_uninit_extra` feature unnecessary.
…h726 Add test cases for issue rust-lang#26186 Closes rust-lang#26186 It seems that issue rust-lang#26186 has been solved at some point since the issue has been last updated. I've merged together the examples that were supplied by `@Osspial,` `@Mark-Simulacrum,` `@Diggsey,` `@eefriedman` and `@shepmaster,` so that we can add this to the testing suite and prevent these issues from re-occurring.
…melid Fix minor typos
rustbot
added
T-compiler
|
@bors r+ rollup=never p=7 |
|
📌 Commit eab8129 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
This was referenced Dec 28, 2021
|
Finished benchmarking commit (4ee34f3): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
base_exprtwice in type_changing_struct_update #92112 (Fix the error of checkingbase_exprtwice in type_changing_struct_update)maybe_uninit_extrafeature from Vec docs #92264 (Removemaybe_uninit_extrafeature from Vec docs)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup