Reorder the parameter descriptions of map_or and map_or_else
They were described backwards, probably leading users to write arguments in the wrong order. Bug: #84608
Fix coverage ICE because fn_sig can have a span that crosses file bou…
Fixes: #83792
MIR `InstrumentCoverage` assumed the `FnSig` span was contained within a
single file, but this is not always the case. Some macro constructions
can result in a span that starts in one `SourceFile` and ends in a
different one.
The `FnSig` span is included in coverage results as long as that span is
in the same `SourceFile` and the same macro context, but by assuming the
`FnSig` span's `hi()` and `lo()` were in the same file, I took this for
granted, and checked only that the `FnSig` `hi()` was in the same
`SourceFile` as the `body_span`.
I actually drop the `hi()` though, and extend the `FnSig` span to the
`body_span.lo()`, so I really should have simply checked that the
`FnSig` span's `lo()` was in the `SourceFile` of the `body_span`.
r? `@tmandry`
cc: `@wesleywiser`
Add the `try_trait_v2` library basics
No compiler changes as part of this -- just new unstable traits and impls thereof.
The goal here is to add the things that aren't going to break anything, to keep the feature implementation simpler in the next PR.
(Draft since the FCP won't end until Saturday, but I was feeling optimistic today -- and had forgotten that FCP was 10 days, not 7 days.)
Unify the docs of std::env::{args_os, args} more
I noticed that `args_os` was missing some information and I thought it should mention `args` for when you want more safety just like how `args` mentions `args_os` if you don't want it to panic on invalid Unicode.
Stabilize Duration::MAX
Following the suggested direction from https://github.com/rust-lang/rust/issues/76416#issuecomment-817278338, this PR proposes that `Duration::MAX` should have been part of the `duration_saturating_ops` feature flag all along, having been
0. heavily referenced by that feature flag
1. an odd duck next to most of `duration_constants`, as I expressed in https://github.com/rust-lang/rust/issues/57391#issuecomment-717681193
2. introduced in #76114 which added `duration_saturating_ops`
and accordingly should be folded into `duration_saturating_ops` and therefore stabilized.
r? `@m-ou-se`
Remove slice diagnostic item
...because it is unusally placed on an impl and is redundant with a lang item.
Depends on rust-lang/rust-clippy#7074 (next clippy sync). ~I expect clippy tests to fail in the meantime.~ Nope tests passed...
CC `@flip1995`
Fix typo in report_unsed_assign
The function was called `report_unsed_assign`, which I assume is a typo, considering the rest of the file.
This replaces `report_unsed_assign` with `report_unused_assign`.
Always reject `const fn` in `trait` during parsing.
'const fn' in trait are rejected in the AST:
b78c0d8a4d/compiler/rustc_ast_passes/src/ast_validation.rs (L1411)
So this feature gate check is a NOP and we can just remove it.
The src/test/ui/feature-gates/feature-gate-min_const_fn.rs and src/test/ui/feature-gates/feature-gate-const_fn.rs tests ensure that we still reject `const fn` in `trait`
Cc https://github.com/rust-lang/rust/issues/84510
r? `@oli-obk`
Rollup of 8 pull requests
Successful merges:
- #84235 (refactor StyledBuffer)
- #84450 (Give a better error when `std` or `core` are missing)
- #84486 (Handle pretty printing of `else if let` clauses without ICEing)
- #84499 (Tweak trait not `use`d suggestion)
- #84516 (Add suggestion to "use break" when attempting to implicit-break a loop)
- #84520 (Improve diagnostics for function passed when a type was expected.)
- #84541 (Inline most raw socket, fd and handle conversions)
- #84547 (Get rid of is_min_const_fn)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Get rid of is_min_const_fn
This removes the last trace of the min_const_fn mechanism by making the unsafety checker agnostic about whether something is a min or "non-min" const fn. It seems this distinction was used to disallow some features inside `const fn`, but that is the responsibility of the const checker, not of the unsafety checker. No test seems to even notice this change in the unsafety checker so I guess we are good...
r? `@oli-obk`
Cc https://github.com/rust-lang/rust/issues/84510
Inline most raw socket, fd and handle conversions
Now that file descriptor types on Unix have niches, it is advantageous for user libraries which provide file descriptor wrappers (e.g. `Socket` from socket2) to store a `File` internally instead of a `RawFd`, so that the niche can be taken advantage of. However, doing so will currently result in worse performance as `IntoRawFd`, `FromRawFd` and `AsRawFd` are not inlined. This change adds `#[inline]` to those methods on std types that wrap file descriptors, handles or sockets.
Improve diagnostics for function passed when a type was expected.
This PR improves diagnostics, it provides more information when a function is passed where a type is expected.
r? `@lcnr`
Handle pretty printing of `else if let` clauses without ICEing
When pretty printing the HIR of `if ... {} else if let ... {}` clauses, this displays it the `else if let` part as `match` it gets desugared to, the same way normal `if let` statements are currently displayed, instead of ICEing.
```rust
pub fn main() {
if true {
// 1
} else if let a = 1 {
// 2
} else {
// 3
}
}
```
now gets desugared (via `rustc -Zunpretty=hir,typed src/x.rs`) to:
```rust
#[prelude_import]
use ::std::prelude::rust_2015::*;
#[macro_use]
extern crate std;
pub fn main() ({
(if (true as bool)
({
// 1
} as
()) else {match (1 as i32) {
a => {
// 2
}
_ => {
// 3
}
}} as ())
} as ())
```
For comparison, this code gets HIR prettyprinted the same way before and after this change:
```rust
pub fn main() {
if let a = 1 {
// 2
} else {
// 3
}
}
```
turns into
```rust
#[prelude_import]
use ::std::prelude::rust_2015::*;
#[macro_use]
extern crate std;
pub fn main() ({
(match (1 as i32) {
a => {
// 2
}
_ => {
// 3
}
} as ())
} as ())
```
This closes#82329. It closes#84434 as well, due to having the same root cause.
Give a better error when `std` or `core` are missing
- Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this, but it seems harmless enough and it will be a big help.
- On nightly, suggest using `cargo build -Z build-std` if `CARGO` is set
- Add a note about `#![no_std]` if `std` is missing but not core
- Add a note that std may be unsupported if `std` is missing but not core
Fixes https://github.com/rust-lang/rust/issues/84418.
r? `@petrochenkov`
rustdoc: make expand/collapse all ephemeral
The `[+]` in the upper right of a rustdoc page expands or collapses all toggles on the page. That state is stored across page loads, but is used inconsistently. This change explicitly stops storing or using the state.
This also moves the code for toggling display of trait implementations so that it's near the other toggling code.
Fixes#84318
- Suggest using `rustup target add` if `RUSTUP_HOME` is set. I don't know if there's any precedent for doing this, but it seems harmless enough and it will be a big help.
- Add a note about `#![no_std]` if `std` is missing but not core
- On nightly, suggest using `cargo build -Z build-std` if `CARGO` is set
- Add a note that std may be unsupported if `std` is missing but not core
- Don't suggest `#![no_std]` when the load isn't injected by the
compiler
various const parameter defaults improvements
Actually resolve names in const parameter defaults, fixing `struct Foo<const N: usize = { usize::MAX }>`.
---
Split generic parameter ban rib for types and consts, allowing
```rust
#![feature(const_generics_defaults)]
struct Q;
struct Foo<T = Q, const Q: usize = 3>(T);
```
---
Remove the type/const ordering restriction if `const_generics_defaults` is active, even if `const_generics` is not. allowing us to stabilize and test const param defaults separately.
---
Check well formedness of const parameter defaults, eagerly emitting an error for `struct Foo<const N: usize = { 0 - 1 }>`
---
Do not forbid const parameters in param defaults, allowing `struct Foo<const N: usize, T = [u8; N]>(T)` and `struct Foo<const N: usize, const M: usize = N>`. Note that this should not change anything which is stabilized, as on stable, type parameters must be in front of const parameters, which means that type parameter defaults are only allowed if no const parameters exist.
We still forbid generic parameters inside of const param types.
r? `@varkor` `@petrochenkov`
