`needless_return` suggest return unit type on void returns
closes#8177
previously, `needless_return` suggests an empty block `{}` to replace void `return` on match arms, this PR improve the suggestion by suggesting a unit instead.
changelog: `needless_return` suggests `()` instead of `{}` on match arms
closes#8177
previously, `needless_return` suggests an empty block `{}` to replace void `return` on match arms, this PR improve the suggestion by suggesting a unit instead.
changelog: `needless_return` suggests `()` instead of `{}` on match arms
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
rustc_metadata: Switch crate data iteration from a callback to iterator
The iteration looks more conventional this way, and some allocations are avoided.
cache test item names
This avoids quadratic behavior (collecting all test item names for each `eq_op` instance within the module). However, it invests a good deal of memory to buy this speedup. If that becomes a problem, I may need to change the cache to only store the chain of last visited modules.
This hopefully fixes#8171.
---
changelog: none
intra-doc: Use an enum to represent URL fragments
This is a step in the direction of computing the links more lazily,
which I think will simplify the implementation of intra-doc links.
This will also make it easier to eventually use the actual `Res` for
associated items, enum variants, and fields, rather than their HTML
page's `Res`.
r? `@jyn514`
Now the only two crate-public items are `build_index` and
`get_index_search_type` (because for some reason the latter is also used
in `formats::cache`).
It was previously defined in `render::search_index` but wasn't used at
all there. `clean::types` seems like a better fit since that's where
`ExternalCrate` is defined.
This is a step in the direction of computing the links more lazily,
which I think will simplify the implementation of intra-doc links.
This will also make it easier to eventually use the actual `Res` for
associated items, enum variants, and fields, rather than their HTML
page's `Res`.
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.
