ty/print: pretty-print constant aggregates (arrays, tuples and ADTs).
Oddly enough, we don't have any UI tests showing this off in types, only `mir-opt` tests.
However, the pretty form should show up in the test output diff of #71018, if this PR is merged first.
<hr/>
Examples of before/after:
|`Option<bool>`|
|:-:|
|`{transmute(0x01): std::option::Option<bool>}`|
| ✨ ↓↓↓ ✨ |
|`std::option::Option::<bool>::Some(true)`|
| `RawVec<u32>` |
|:-:|
| `ByRef { alloc: Allocation { bytes: [4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], relocations: Relocations(SortedMap { data: [] }), undef_mask: UndefMask { blocks: [65535], len: Size { raw: 16 } }, size: Size { raw: 16 }, align: Align { pow2: 3 }, mutability: Not, extra: () }, offset: Size { raw: 0 } }: alloc::raw_vec::RawVec::<u32>`|
| ✨ ↓↓↓ ✨ |
|`alloc::raw_vec::RawVec::<u32> { ptr: std::ptr::Unique::<u32> { pointer: {0x4 as *const u32}, _marker: std::marker::PhantomData::<u32> }, cap: 0usize, alloc: std::alloc::Global }`|
<hr/>
This PR is a prerequisite for #61486, *sort of*, in that we need to be able to pretty-print values in order to even consider how we might mangle them.
We still don't have pretty-printing for constants of reference types, @oli-obk has the necessary support logic in a PR but I didn't want to interfere with that.
<hr/>
Each commit should be reviewed separately, as I've fixed a couple deficiencies along the way.
r? @oli-obk cc @rust-lang/wg-mir-opt @varkor @yodaldevoid
Deprecate the asm! macro in favor of llvm_asm!
Since we will be changing the syntax of `asm!` soon, deprecate it and encourage people to use `llvm_asm!` instead (which preserves the old syntax). This will avoid breakage when `asm!` is changed.
RFC: https://github.com/rust-lang/rfcs/pull/2843
Make the necessary changes to support concurrency in Miri.
This pull request makes the necessary changes to the Rust compiler to allow Miri to support concurrency:
1. Move stack from the interpretation context (`InterpCx`) to machine, so that the machine can switch the stacks when it changes the thread being executed.
2. Add the callbacks that allow the machine to generate fresh allocation ids for each thread local allocation and to translate them back to original allocations when needed. This allows the machine to ensure the property that allocation ids are unique, which allows using a simpler representation of the memory.
r? @oli-obk
cc @RalfJung
Rollup of 4 pull requests
Successful merges:
- #71026 (Fix false "never constructed" warnings for `Self::` variant paths)
- #71310 (Do not show DefId in diagnostics)
- #71317 (miri-unleash test for llvm_asm)
- #71324 (Fix some tests failing in `--pass check` mode)
Failed merges:
r? @ghost
Rollup of 5 pull requests
Successful merges:
- #71107 (Address concerns of weak-into-raw)
- #71188 (Fixed missing trait method suggests incorrect code (self parameter not named "self"). )
- #71300 (Clarify when to use the tracking issue template)
- #71315 (Add example in the alternative in std::mem::transmute docs)
- #71319 (Clean up E0522 explanation)
Failed merges:
r? @ghost
Address concerns of weak-into-raw
This should address the standing concerns in https://github.com/rust-lang/rust/issues/60728#issuecomment-612525616.
I've still left the ability to create a new dangling pointer from `null`, as I feel like this is the natural behaviour to expect, but I'm fine removing that too. I've modified the documentation to allow the `as_ptr` or `into_ptr` to return whatever garbage in case of a dangling pointer. I've also removed the guarantee to be able to do `from_raw(as_ptr)` from the documentation (but it would still work right now).
I've renamed the method and added implementations for `Rc`/`Arc`.
I've also tried if I can just „enable“ unsized types. I believe the current interface is compatible with them. But the inner implementation will be a bit challenging ‒ I can't use the `data_offset` as is used by `Rc` or `Arc` because it AFAIK „touches“ (creates a reference to) the live value of `T` ‒ and in case of `Weak`, it might be completely bogus or already dead ‒ so that would be UB.
`./x.py test tidy` is completely mad on my own system all over the code base :-(. I'll just hope it goes through CI, or will fix as necessary.
Is it OK if I ask @Amanieu for review, as the concerns are from you?
~r @Amanieu
With the exception of `-C no-redzone`, because that could take a value
before this PR.
This partially undoes one of the earlier commits in this PR, which added
the ability to take a value to all boolean options that lacked it.
The help output for these options looks like this:
```
-C no-vectorize-slp=val -- disable LLVM's SLP vectorization pass
```
The "=val" part is a lie, but hopefully this will be fixed in the future.
This commit:
- Adds "following values" indicators for all the options that are
missing them.
- Tweaks some wording and punctuation for consistency.
- Rewords some things for clarity.
- Removes the `no-integrated-as` entry, because that option was removed
in #70345.
For all `-C` and `-Z` options that have them.
The commit also rewords a few options to make them clearer, mostly by
avoiding the word "don't".
It also removes the listed default for `-Cinline-threshold`, which is
incorrect -- that option doesn't have a static default.
Make `needs_drop` less pessimistic on generators
Generators only have non-trivial drop logic when they may store (in upvars or across yields) a type that does.
This prevents generation of some unnecessary MIR in simple generators. There might be some impact on compile times, but this is probably limited in real-world applications.
~~This builds off of https://github.com/rust-lang/rust/pull/69814 since that contains some fixes that are made relevant by *this* PR (see https://github.com/rust-lang/rust/pull/69814#issuecomment-599147269).~~ (this has been merged)
This lets us specify the default at the options declaration point,
instead of using `.unwrap(default)` or `None | Some(default)` at some
use point far away. It also makes the code more concise.
Currently, if you give a bogus value like
`-Zsanitizer-memory-track-origins=99` you get this incorrect error:
```
error: debugging option `sanitizer-memory-track-origins` takes no value
```
This commit fixes it so it gives this instead:
```
error: incorrect value `99` for debugging option `sanitizer-memory-track-origins` - 0, 1, or 2 was expected
```
The commit also makes `parse_sanitizer_memory_track_origins` more
readable.
