Rollup of 7 pull requests
Successful merges:
- #90586 (Relax priv-in-pub lint on generic bounds and where clauses of trait impls.)
- #92112 (Fix the error of checking `base_expr` twice in type_changing_struct_update)
- #92147 (rustc_builtin_macros: make asm mod public for rustfmt)
- #92161 (resolve: Minor miscellaneous cleanups from #89059)
- #92264 (Remove `maybe_uninit_extra` feature from Vec docs)
- #92303 (Add test cases for issue #26186)
- #92307 (Fix minor typos)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Readme: note that config changes don't apply to already compiled code
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: added a note to the Readme that config changes don't apply to already compiled code
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: added a note to the Readme that config changes don't apply to already compiled code
Add test cases for issue #26186Closes#26186
It seems that issue #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.
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.
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 #79291.
Rustdoc: use `is_doc_hidden` method on more places
While profiling `rustdoc`, I noticed that finding out if some item is marked with `#[doc(hidden)]` is relatively hot, so I tried to optimize it.
I noticed that there is already a method called `is_doc_hidden` on `TyCtxt`, but it wasn't used much, so I replaced the manual calls to `attrs(...).has_word(...)` with this method. Just by doing that, perf. was improved locally, although I'm not sure if the semantics of the previous calls and this method are the same?
As another step, I tried to querify `is_doc_hidden`, but I didn't include that here until we see the perf. results from the first commit and until I find whether this change is OK at all :)
Can I ask for a perf. run? Thanks.
r? `@jyn514`
`enum_variant_names` will consider characters with no case to be a part
of prefixes/suffixes substring that are compared. This means `Foo1` and
`Foo2` has different prefixes (`Foo1` and `Foo2` prefix respeectively).
This applies to all non-ascii characters with no casing.
fix an ICE on unwrapping a None
This very likely fixes#8166 though I wasn't able to meaningfully reduce a test case. This line is the only call to `unwrap` within that function, which was the one in the stack trace that triggered the ICE, so I think we'll be OK.
`@hackmad` can you pull and build this branch and check if it indeed fixes your problem?
---
changelog: Fixed ICE in [`unnecessary_cast`]
