add mips64r6 and mips32r6 as target_arch values
This PR introduces `"mips32r6"` and `"mips64r6"` as valid `target_arch` values, and would be the arch value used by Tier-3 targets `mipsisa32r6-unknown-linux-gnu`, `mipsisa32r6el-unknown-linux-gnu`, `mipsisa64r6-unknown-linux-gnuabi64` and `mipsisa64r6el-unknown-linux-gnuabi64`.
This PR was inspired by `rustix` attempting to link traditional mips64el objects with mips64r6el objects when building for mips64r6, even though `rustix` recently removed outline assembly support. This is because currently this target's `target_arch` is `"mips64"` and rustix has its respective assembly implementation as well as a pre-compiled little-endian static library prepared for mips64el, a tier-2 target with the same `target_arch`. After some [discussions on zulip](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Add.20New.20Values.20To.20MIPS_ALLOWED_FEATURES.20compiler-team.23595), I decided to treat mips64r6 as an independent architecture from Rust's POV, since these two architectures are incompatible anyway.
This PR is now waiting for `libc` to release a new version with [support](https://github.com/rust-lang/libc/pull/3268) for these `target_arch` values. It is not expected to introduce changes to any other target, especially Tier-1 and Tier-2 targets.
This PR has its corresponding [MCP](https://github.com/rust-lang/compiler-team/issues/632) approved.
Fix compiletest windows path finding with spaces
With `(?x)` enabled spaces are ignored unless you escape them, so the space wasn't being added to the character class
I don't think this makes any difference to the current test suite, but it could save someone a headache in the future
In the current documentation, it's not specified that when creating
a Command, the .exe extension can be omitted for Windows executables.
However, for other types of executable files like .bat or .cmd,
the complete filename including the extension must be provided.
I encountered it by noticing that `Command::new("wt").spawn().unwrap()`
succeeds on my machine while `Command::new("code").spawn().unwrap()`
panics. Turns out VS Code's entrypoint is .cmd file.
`resolve_exe` method mentions this behaviour in a comment[1], but it
makes sense to mention it at more visible place.
I've added this clarification to the documentation, which should
make it more accurate and helpful for Rust developers
working on the Windows platform.
[1] e7fda447e7/library/std/src/sys/windows/process.rs (L425)
Safe Transmute: Fix ICE (due to UnevaluatedConst)
This patch updates the code that looks at the `Assume` type when evaluating if transmutation is possible. An ICE was being triggered in the case that the `Assume` parameter contained an unevaluated const (in this test case, due to a function with missing parameter names).
Fixes#110892
Rename `arg_iter` to `iter_instantiated`
`arg_iter` doesn't make sense, and doesn't really indicate what it's doing (returning an iterator that ~~substitutes~~ instantiates its elements).
`iter_instantiated_copied` is kinda awkward but i don't really wanna bikeshed it.
r? `@oli-obk`
Add x86_64-unknown-linux-ohos target
This complements the existing `aarch64-unknown-linux-ohos` and `armv7-unknown-linux-ohos` targets.
This should be covered by the existing MCP (https://github.com/rust-lang/compiler-team/issues/568), but I can also create a new MCP if that is preferred.
Add support for allocators in `Rc` & `Arc`
Adds the ability for `std::rc:Rc`, `std::rc::Weak`, `std::sync::Arc`, and `std::sync::Weak` to live in custom allocators
When dlltool fails, show the full command that was executed. In
particular, llvm-dlltool is not very helpful, printing a generic usage
message rather than what actually went wrong, so stdout and stderr
aren't of much use when troubleshooting.
miri: fail when calling a function that requires an unavailable target feature
miri will report an UB when calling a function that has a `#[target_feature(enable = ...)]` attribute is called and the required feature is not available.
"Available features" are the same that `is_x86_feature_detected!` (or equivalent) reports to be available during miri execution (which can be enabled or disabled with the `-C target-feature` flag).
