Fix ICE while building MIR with type errors
See https://github.com/rust-lang/rust/issues/74047#issuecomment-663290913 for background. Replacing a binding with `PatKind::Wild` (introduced in #51789 and later refactored in #67439) caused an ICE downstream while building MIR.
I noticed that taking this code out no longer triggers the ICEs it was added to prevent. I'm not sure what else changed, or if this change is _correct_, but it does seem to be passing ui tests at least.
r? @oli-obk
cc @estebank
Fixes#74047.
Remove needless unsafety from BTreeMap::drain_filter
Remove one piece of unsafe code in the iteration over the iterator returned by BTreeMap::drain_filter.
- Changes an explicitly unspecified part of the API: when the user-supplied predicate (or some of BTreeMap's code) panicked, and the caller tries to use the iterator again, we no longer offer the same key/value pair to the predicate again but pretend the iterator has finished. Note that Miri does not find UB in the test case added here with the unsafe code (or without).
- Makes the code a little easier on the eyes.
- Makes the code a little harder on the CPU:
```
benchcmp c0 c2 --threshold 3
name c0 ns/iter c2 ns/iter diff ns/iter diff % speedup
btree::set::clone_100_and_drain_all 2,794 2,900 106 3.79% x 0.96
btree::set::clone_100_and_drain_half 2,604 2,964 360 13.82% x 0.88
btree::set::clone_10k_and_drain_half 287,770 322,755 34,985 12.16% x 0.89
```
r? @Amanieu
More BTreeMap test cases, some exposing undefined behaviour
Gathered from other ongoing PRs and all either blessed or ignored by Miri
r? @Mark-Simulacrum
Internally unify rustc_deprecated and deprecated
This PR intentionally tries to be "featureless" in that the behavior is not altered for either attribute, though it more clearly exposes cases where that is the case in the code.
Use `(std::)f64::EPSILON` in the examples as suggested in the lints
`float_cmp(_const)` suggests using `{f32|f64}::EPSILON` and it'd be great if the docs mentioned it.
changelog: none
Revert libbacktrace -> gimli
This reverts 4cbd265c11028f8d7b8513db3cc1e8d7a36d8964 (and technically 79673d3009 but it's made empty by previous reverts).
The current plan is to land this PR as a temporary change, so that we can get a better handle on the regressions introduced by it. Trying to fix/examine them in master is difficult, and we want to be better able to evaluate them without impact to other PRs being landed in the mean time.
That said, it is currently *my* belief that gimli, in one form or another, will need to land sometime soon. I think it's quite likely that it may slip a week or two, but I would personally push for re-landing it then "regardless" of the regressions. We should try to focus efforts on understanding and removing as much of the performance impact as possible, as everyone pretty much agrees that it should be quite minimal (and entirely in the linker, basically).
r? @nnethercote
Rollup of 8 pull requests
Successful merges:
- #74141 (libstd/libcore: fix various typos)
- #74490 (add a Backtrace::disabled function)
- #74548 (one more Path::with_extension example, to demonstrate behavior)
- #74587 (Prefer constant over function)
- #74606 (Remove Linux workarounds for missing CLOEXEC support)
- #74637 (Make str point to primitive page)
- #74654 (require type defaults to be after const generic parameters)
- #74659 (Improve codegen for unchecked float casts on wasm)
Failed merges:
r? @ghost
Improve codegen for unchecked float casts on wasm
This commit improves codegen for unchecked casts on WebAssembly targets
to use the singluar `iNN.trunc_fMM_{u,s}` instructions. Previously rustc
would codegen a bare `fptosi` and `fptoui` for float casts but for
WebAssembly targets the codegen for these instructions is quite large.
This large codegen is due to the fact that LLVM can speculate these
instructions so the trapping behavior of WebAssembly needs to be
protected against in case they're speculated.
The change here is to update the codegen for the unchecked cast
intrinsics to have a wasm-specific case where they call the appropriate
LLVM intrinsic to generate the right wasm instruction. The intrinsic is
explicitly opting-in to undefined behavior so a trap here for
out-of-bounds inputs on wasm should be acceptable.
cc #73591
require type defaults to be after const generic parameters
From current discussions it seems like the goal here is for type and const parameters to be unordered and allow things like `struct Foo<const N: usize, T = u32>(T)` and `struct Foo<T, const N: usize = 7>` this way.
Note: This means that using `min_const_generics` it will not be possible for an adt to have both type defaults and const parameters.
closes#70471
r? @varkor @eddyb
