Raise minimum supported Apple OS versions
This implements the proposal to raise the minimum supported Apple OS versions as laid out in the now-completed MCP (https://github.com/rust-lang/compiler-team/issues/556).
As of this PR, rustc and the stdlib now support these versions as the baseline:
- macOS: 10.12 Sierra
- iOS: 10
- tvOS: 10
- watchOS: 5 (Unchanged)
In addition to everything this breaks indirectly, these changes also erase the `armv7-apple-ios` target (currently tier 3) because the oldest supported iOS device now uses ARMv7s. Not sure what the policy around tier3 target removal is but shimming it is not an option due to the linker refusing.
[Per comment](https://github.com/rust-lang/compiler-team/issues/556#issuecomment-1297175073), this requires a FCP to merge. cc `@wesleywiser.`
adjust how closure/generator types are printed
I saw `&[closure@$DIR/issue-20862.rs:2:5]` and I thought it is a slice type, because that's usually what `&[_]` is... it took me a while to realize that this is just a confusing printer and actually there's no slice. Let's use something that cannot be mistaken for a regular type.
Suggest desugaring to return-position `impl Future` when an `async fn` in trait fails an auto trait bound
First commit allows us to store the span of the `async` keyword in HIR.
Second commit implements a suggestion to desugar an `async fn` to a return-position `impl Future` in trait to slightly improve the `Send` situation being discussed in #115822.
This suggestion is only made when `#![feature(return_type_notation)]` is not enabled -- if it is, we should instead suggest an appropriate where-clause bound.
interpret: more consistently use ImmTy in operators and casts
The diff in src/tools/miri/src/shims/x86/sse2.rs should hopefully suffice to explain why this is nicer. :)
rename mir::Constant -> mir::ConstOperand, mir::ConstKind -> mir::Const
Also, be more consistent with the `to/eval_bits` methods... we had some that take a type and some that take a size, and then sometimes the one that takes a type is called `bits_for_ty`.
Turns out that `ty::Const`/`mir::ConstKind` carry their type with them, so we don't need to even pass the type to those `eval_bits` functions at all.
However this is not properly consistent yet: in `ty` we have most of the methods on `ty::Const`, but in `mir` we have them on `mir::ConstKind`. And indeed those two types are the ones that correspond to each other. So `mir::ConstantKind` should actually be renamed to `mir::Const`. But what to do with `mir::Constant`? It carries around a span, that's really more like a constant operand that appears as a MIR operand... it's more suited for `syntax.rs` than `consts.rs`, but the bigger question is, which name should it get if we want to align the `mir` and `ty` types? `ConstOperand`? `ConstOp`? `Literal`? It's not a literal but it has a field called `literal` so it would at least be consistently wrong-ish...
``@oli-obk`` any ideas?
style-guide: Document formatting of `as` casts (mostly like a binary operator)
`as` casts currently get formatted like a binary operator, except that
the second line can stack several `as` casts rather than breaking them
each onto their own line. Document this.
As far as I can tell (cc `@calebcartwright` for verification), this is not a 2024 edition change, it just documents current behavior.
adjust ConstValue::Slice to work for arbitrary slice types
valtrees have already been assuming that this works; this PR makes it a reality. Also further restrict `ConstValue::Slice` to what it is actually used for; this even shrinks `ConstValue` from 32 to 24 bytes which is a nice win. :)
The alternative to this approach is to make `ConstValue::Slice` work really only for `&str`/`&[u8]` literals, and never return it in `op_to_const`. That would make `op_to_const` very clean. We could then even remove the `meta` field; the length would always be `data.inner().len()`. We could *almost* just use a `Symbol` instead of a `ConstAllocation`, but we have to support byte strings and there doesn't seem to be an interned representation of them (or rather, `ConstAllocation` *is* their interned representation). In this world, valtrees of slice reference types would then become noticeably more expensive to turn into a `ConstValue` -- but does that matter? Specifically for `&str`/`&[u8]` we could still use the optimized representation if we wanted.
If byte strings were already interned somewhere I'd gravitate towards the alternative, but the way things stand, we need a `ConstAllocation` case anyway to support byte strings, and then we might as well support arbitrary slices. (Or we say that byte strings don't get an optimized representation at all. Such a performance cliff between `str` and byte strings is probably unexpected, though due to the lack of interning for byte strings I think there might already be a performance cliff there.)
Ensure `build/tmp` exists in `rustdoc_themes::get_themes`
This causes failures in ferrocene's CI as `build/tmp` might not exist at this point, causing the following expect to fail here 4b91288484/src/tools/rustdoc-themes/main.rs (L24)
dependencies: reduce the amount of crates pulling in atty
It would be nice to have only one `hermit-abi` in `Cargo.lock` (https://github.com/rust-lang/rust/pull/107405#issuecomment-1427116590).
The only crate pulling in the old `hermit-abi` version is `atty`, which is unmaintained.
This PR upgrades three dependencies, which then no longer depend on `atty`:
* `Cargo.lock`: `colored v2.0.0 -> v2.0.4`
* `Cargo.lock`: `tracing-tree v0.2.3 -> v0.2.4`
* Miri: `env_logger 0.9.3 -> 0.10.0`
The only dependency chain left that pulls in `hermit-abi 0.1.19` is:
`hermit-abi 0.1.19` -> `atty 0.2.14` -> `env_logger 0.7.1` -> `jsonpath_lib 0.2.6` -> `jsondocck 0.1.0` (src/tools/jsondocck)
Replacing jsondocck with jsondocckng is tracked in https://github.com/rust-lang/rust/issues/94140.
miri: reduce code duplication in some SSE/SSE2 intrinsics
Reduces code duplication in the Miri implementation of some SSE and SSE2 using generics and rustc_const_eval helper functions.
There are also some other minor changes.
r? `@RalfJung`
