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`
Pretty-print argument-position impl trait to name it.
This removes a corner case.
RPIT and TAIT keep having no name, and it would be wrong to use the one in HIR (Ident::empty), so I make this case ICE.
Custom code classes in docs warning
Fixes https://github.com/rust-lang/rust/issues/115938.
This PR does two things:
1. Unless the `custom_code_classes_in_docs` feature is enabled, it will use the old codeblock tag parser.
2. If there is a codeblock tag that starts with a `.`, it will emit a behaviour change warning.
Hopefully this is the last missing part for this feature until stabilization.
Follow-up of https://github.com/rust-lang/rust/pull/110800.
r? `@notriddle`
This reduces the amount of dependencies pulling in atty.
```
Removing env_logger v0.9.3
```
Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de>
This reduces the amount of dependencies pulling in atty.
```
Updating colored v2.0.0 -> v2.0.4
Updating tracing-tree v0.2.3 -> v0.2.4
```
Signed-off-by: Martin Kröning <martin.kroening@eonerc.rwth-aachen.de>
