Add back unwinding support for Sony PSP
This PR adds back unwinding support for the Sony PSP. The `mipsel-sony-psp` target works well with unwinding. In [rust-psp], we use the `panic_unwind` crate along with LLVM's libunwind to catch panics, run destructors, and print them to the debug screen without aborting all threads.
[rust-psp]: https://github.com/overdrivenpotato/rust-psp
This commit fixes an issue with #74695 where the fptosi and fptoui
specializations on wasm were accidentally used on vector types by the
`simd_cast` intrinsic. This issue showed up as broken CI for the stdsimd
crate. Here this commit simply skips the specialization on vector kinds
flowing into `fpto{s,u}i`.
Rollup of 15 pull requests
Successful merges:
- #74712 (Update E0271 explanation)
- #74842 (adjust remaining targets)
- #75151 (Consistent variable name alloc for raw_vec)
- #75162 (Fix the documentation for move about Fn traits implementations)
- #75248 (Add `as_mut_ptr` to `NonNull<[T]>`)
- #75262 (Show multi extension example for Path in doctests)
- #75266 (Add safety section to `NonNull::as_*` method docs)
- #75284 (Show relative example for Path ancestors)
- #75285 (Separate example for Path strip_prefix)
- #75287 (Show Path extension example change multi extension)
- #75288 (Use assert! for Path exists example to check bool)
- #75289 (Remove ambiguity from PathBuf pop example)
- #75290 (fix `min_const_generics` version)
- #75291 (Clean up E0750)
- #75292 (Clean up E0502)
Failed merges:
r? @ghost
Add safety section to `NonNull::as_*` method docs
This basically adds the safety section of `*mut T::as_{ref,mut}` to the
same methods on `NonNull` with minor modifications to fit the
differences.
Part of #48929.
Simplify array::IntoIter
- Initialization can use `transmute_copy` to do the bitwise copy.
- `as_slice` can use `get_unchecked` and `MaybeUninit::slice_get_ref`,
and `as_mut_slice` can do similar.
- `next` and `next_back` can use the corresponding `Range` methods.
- `Clone` doesn't need any unsafety, and we can dynamically update the
new range to get partial drops if `T::clone` panics.
r? @LukasKalbertodt
Implement `into_keys` and `into_values` for associative maps
This PR implements `into_keys` and `into_values` for HashMap and BTreeMap types. They are implemented as unstable, under `map_into_keys_values` feature.
Fixes#55214.
r? @dtolnay
polymorphize: unevaluated constants
This PR makes polymorphization visit the promoted MIR of unevaluated constants with available promoted MIR instead of visiting the substitutions of that constant - which will mark all of the generic parameters as used; in addition polymorphization will now visit non-promoted unevaluated constants rather than visit their substs.
r? @lcnr
Renamed remaining references to "undef" to "uninit" when referring to Miri.
Impacted directories are:
- src/librustc_codegen_llvm/consts.rs
- src/librustc_middle/mir/interpret/
- src/librustc_middle/ty/print/pretty.rs
- src/librustc_mir/
- src/tools/clippy/clippy_lints/src/consts.rs
Upon building Miri based on the new changes it was verified that no changes needed to be made with the Miri project.
Related issue #71193
Emit == null instead of <= null for niche check
When the niche maximum is zero, emit a "== zero" check instead of a "<= zero" check. In particular, this avoids the awkward case of "<= null". While LLVM does canonicalize this to "== null", this apparently doesn't happen for constant expressions, leading to the issue in #74425. While that can be addressed on the LLVM side, it still seems prudent to emit sensible IR here, because this will allow null checks to be optimized earlier in the pipeline.
Fixes#74425.
This basically adds the safety section of `*mut T::as_{ref,mut}` to the
same methods on `NonNull` with minor modifications to fit the
differences.
Part of #48929.
When the niche maximum is zero, emit a "== zero" check instead of
a "<= zero" check. In particular, this avoid the awkward case of
"<= null". While LLVM does canonicalize this to "!= null", this
appently doesn't happen for constant expressions, leading to the
issue in #74425. While that can be addressed on the LLVM side, it
still seems prudent to emit sensible IR here, because this will
allow null checks to be optimized earlier in the pipeline.
Fixes#74425.
