Add section on common message styles for Result::expect
Based on a question from https://github.com/rust-lang/project-error-handling/issues/50#issuecomment-1092339937
~~One thing I haven't decided on yet, should I duplicate this section on `Option::expect`, link to this section, or move it somewhere else and link to that location from both docs?~~: I ended up moving the section to `std::error` and referencing it from both `Result::expect` and `Option::expect`'s docs.
I think this section, when combined with the similar update I made on [`std::panic!`](https://doc.rust-lang.org/nightly/std/macro.panic.html#when-to-use-panic-vs-result) implies that we should possibly more aggressively encourage and support the "expect as precondition" style described in this section. The consensus among the libs team seems to be that panic should be used for bugs, not expected potential failure modes. The "expect as error message" style seems to align better with the panic for unrecoverable errors style where they're seen as normal errors where the only difference is a desire to kill the current execution unit (aka erlang style error handling). I'm wondering if we should be providing a panic hook similar to `human-panic` or more strongly recommending the "expect as precondition" style of expect message.
improve case conversion happy path
Someone shared the source code for [Go's string case conversion](19156a5474/src/strings/strings.go (L558-L616)).
It features a hot path for ascii-only strings (although I assume for reasons specific to go, they've opted for a read safe hot loop).
I've borrowed these ideas and also kept our existing code to provide a fast path + seamless utf-8 correct path fallback.
(Naive) Benchmarks can be found here https://github.com/conradludgate/case-conv
For the cases where non-ascii is found near the start, the performance of this algorithm does fall back to original speeds and has not had any measurable speed loss
omit `record_accesses` function when collecting `MonoItem`s
This PR fixes the FIXME in the impl of `record_accesses` function.
[Edit] We can call `instantiation_mode` when push the `MonoItem` into `neighbors`. This avoids extra local variables `accesses: SmallVec<[_; 128]>`
Only allow `compiletest` to use `feature(test)`, not any other feature
Using language features occasionally causes issues when using nightly to bootstrap, rather than beta.
See #59264 for additional context.
Simplify implementation of `-Z gcc-ld`
- The logic is now unified for all targets (wasm targets should also be supported now)
- Additional "symlink" files like `ld64` are eliminated
- lld-wrapper is used for propagating the correct lld flavor
- Cleanup "unwrap or exit" logic in lld-wrapper
cc https://github.com/rust-lang/rust/issues/97352
r? `@bjorn3`
- The logic is now unified for all targets (wasm targets should also be supported now)
- Additional "symlink" files like `ld64` are eliminated
- lld-wrapper is used for propagating the correct lld flavor
- Cleanup "unwrap or exit" logic in lld-wrapper
Update cargo
10 commits in a4c1cd0eb6b18082a7e693f5a665548fe1534be4..39ad1039d9e3e1746177bf5d134af4c164f95528
2022-05-20 00:55:25 +0000 to 2022-05-25 00:50:02 +0000
* doc: discuss build script instruction order (rust-lang/cargo#10600)
* Require http-registry URLs to end with a '/' (rust-lang/cargo#10698)
* No printing executable names when running tests and benchmarks with json message format (rust-lang/cargo#10691)
* Restore proper error for crate not in local reg (rust-lang/cargo#10683)
* Update libcurl (rust-lang/cargo#10696)
* Fixed small typos (rust-lang/cargo#10693)
* fix bugs with `workspace` key and `update_toml` (rust-lang/cargo#10685)
* Bump to 0.64.0, update changelog (rust-lang/cargo#10687)
* List C compiler as a build dependency in README (rust-lang/cargo#10678)
* Add unstable `rustc-check-cfg` build script output (rust-lang/cargo#10539)
r? `@ehuss`
Rollup of 5 pull requests
Successful merges:
- #97302 (Do writeback of Closure params before visiting the parent expression)
- #97328 (rustc: Fix ICE in native library error reporting)
- #97351 (Output correct type responsible for structural match violation)
- #97398 (Add regression test for #82830)
- #97400 (Fix a typo on Struct `Substructure`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Output correct type responsible for structural match violation
Previously we included the outermost type that caused a structural match violation in the error message and stated that that type must be annotated with `#[derive(Eq, PartialEq)]` even if it already had that annotation. This PR outputs the correct type in the error message.
Fixes https://github.com/rust-lang/rust/issues/97278
Do writeback of Closure params before visiting the parent expression
This means that given the expression:
```
let x = |a: Vec<_>| {};
```
We will visit the HIR node for `a` before `x`, and report the ambiguity on the former instead of the latter. This also moves writeback for struct field ids and const blocks before, but the ordering of this and walking the expr doesn't seem to matter.
Extend ptr::null and null_mut to all thin (including extern) types
Fixes https://github.com/rust-lang/rust/issues/93959
This change was accepted in https://rust-lang.github.io/rfcs/2580-ptr-meta.html
Note that this changes the signature of **stable** functions. The change should be backward-compatible, but it is **insta-stable** since it cannot (easily, at all?) be made available only through a `#![feature(…)]` opt-in.
The RFC also proposed the same change for `NonNull::dangling`, which makes sense it terms of its signature but not in terms of its implementation. `dangling` uses `align_of()` as an address. But what `align_of()` should be for extern types or whether it should be allowed at all remains an open question.
This commit depends on https://github.com/rust-lang/rust/pull/93977, which is not yet part of the bootstrap compiler. So `#[cfg]` is used to only apply the change in stage 1+. As far a I know bounds cannot be made conditional with `#[cfg]`, so the entire functions are duplicated. This is unfortunate but temporary.
Since this duplication makes it less obvious in the diff, the new definitions differ in:
* More permissive bounds (`Thin` instead of implied `Sized`)
* Different implementation
* Having `rustc_allow_const_fn_unstable(const_fn_trait_bound)`
* Having `rustc_allow_const_fn_unstable(ptr_metadata)`
Minor improvement on else-no-if diagnostic
Don't suggest wrapping in block since it's highly likely to be a missing `if` after `else`. Also rework message a bit (open to further suggestions).
cc: https://github.com/rust-lang/rust/pull/97298#discussion_r880933431
r? `@estebank`
[RFC 2011] Library code
CC https://github.com/rust-lang/rust/pull/96496
Based on https://github.com/dtolnay/case-studies/tree/master/autoref-specialization.
Basically creates two traits with the same method name. One trait is generic over any `T` and the other is specialized to any `T: Printable`.
The compiler will then call the corresponding trait method through auto reference.
```rust
fn main() {
let mut a = Capture::new();
let mut b = Capture::new();
(&Wrapper(&1i32)).try_capture(&mut a); // `try_capture` from `TryCapturePrintable`
(&Wrapper(&vec![1i32])).try_capture(&mut b); // `try_capture` from `TryCaptureGeneric`
assert_eq!(format!("{:?}", a), "1");
assert_eq!(format!("{:?}", b), "N/A");
}
```
r? `@scottmcm`
RFC3239: Implement `cfg(target)` - Part 2
This pull-request implements the compact `cfg(target(..))` part of [RFC 3239](https://github.com/rust-lang/rust/issues/96901).
I recommend reviewing this PR on a per commit basics, because of some moving parts.
cc `@GuillaumeGomez`
r? `@petrochenkov`
Modify MIR building to drop repeat expressions with length zero
Closes#74836 .
Previously, when a user wrote `[foo; 0]` we used to simply leak `foo`. The goal is to fix that. This PR changes MIR building to make `[foo; 0]` equivalent to `{ drop(foo); [] }` in all cases. Of course, this is a breaking change (see below). A crater run did not indicate any regressions though, and given that the previous behavior was almost definitely not what any user wanted, it seems unlikely that anyone was relying on this.
Note that const generics are in general unaffected by this. Inserting the extra `drop` is only meaningful/necessary when `foo` is of a non-`Copy` type, and array repeat expressions with const generic repetition count must always be `Copy`.
Besides the obvious change to behavior associated with the additional drop, there are three categories of examples where this also changes observable behavior. In all of these cases, the new behavior is consistent with what you would get by replacing `[foo; 0]` with `{ drop(foo); [] }`. As such, none of these give the user new powers to express more things.
**No longer allowed in const (breaking)**:
```rust
const _: [String; 0] = [String::new(); 0];
```
This compiles on stable today. Because we now introduce the drop of `String`, this no longer compiles as `String` may not be dropped in a const context.
**Reduced dataflow (non-breaking)**:
```rust
let mut x: i32 = 0;
let r = &x;
let a = [r; 0];
x = 5;
let _b = a;
```
Borrowck rejects this code on stable because it believes there is dataflow between `a` and `r`, and so the lifetime of `r` has to extend to the last statement. This change removes the dataflow and the above code is allowed to compile.
**More const promotion (non-breaking)**:
```rust
let _v: &'static [String; 0] = &[String::new(); 0];
```
This does not compile today because `String` having drop glue keeps it from being const promoted (despite that drop glue never being executed). After this change, this is allowed to compile.
### Alternatives
A previous attempt at this tried to reduce breakage by various tricks. This is still a possibility, but given that crater showed no regressions it seems unclear why we would want to introduce this complexity.
Disallowing `[foo; 0]` completely is also an option, but obviously this is more of a breaking change. I do not know how often this is actually used though.
r? `@oli-obk`
add a deep fast_reject routine
continues the work on #97136.
r? `@nnethercote`
Actually agree with you on the match structure 😆 let's see how that impacted perf 😅
Rollup of 5 pull requests
Successful merges:
- #93604 (Make llvm-libunwind a per-target option)
- #97026 (Change orderings of `Debug` for the Atomic types to `Relaxed`.)
- #97105 (Add tests for lint on type dependent on consts)
- #97323 (Introduce stricter checks for might_permit_raw_init under a debug flag )
- #97379 (Add aliases for `current_dir`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
`match_impl` has two call sites. For one of them (within `rematch_impl`)
the fast reject test isn't necessary, because any rejection would
represent a compiler bug.
This commit moves the fast reject test to the other `match_impl` call
site, in `assemble_candidates_from_impls`. This lets us move the fast
reject test outside the `probe` call in that function. This avoids the
taking of useless snapshots when the fast reject test succeeds, which
gives a performance win when compiling the `bitmaps` and `nalgebra`
crates.
Co-authored-by: name <n.nethercote@gmail.com>
