Implement the special repr(C)-non-clike-enum layout
This is the second half of https://github.com/rust-lang/rfcs/pull/2195
which specifies that
```rust
#[repr(C, u8)]
#[derive(Copy, Clone, Eq, PartialEq, Debug)]
enum MyEnum {
A(u32), // Single primitive value
B { x: u8, y: i16 }, // Composite, and the offset of `y` depends on tag being internal
C, // Empty
D(Option<u32>), // Contains an enum
E(Duration), // Contains a struct
}
```
Has the same layout as
```rust
#[repr(C)]
struct MyEnumRepr {
tag: MyEnumTag,
payload: MyEnumPayload,
}
#[repr(C)]
#[allow(non_snake_case)]
union MyEnumPayload {
A: MyEnumVariantA,
B: MyEnumVariantB,
D: MyEnumVariantD,
E: MyEnumVariantE,
}
#[repr(u8)] #[derive(Copy, Clone)] enum MyEnumTag { A, B, C, D, E }
#[repr(C)] #[derive(Copy, Clone)] struct MyEnumVariantA(u32);
#[repr(C)] #[derive(Copy, Clone)] struct MyEnumVariantB {x: u8, y: i16 }
#[repr(C)] #[derive(Copy, Clone)] struct MyEnumVariantD(Option<u32>);
#[repr(C)] #[derive(Copy, Clone)] struct MyEnumVariantE(Duration);
```
MIR: split Operand::Consume into Copy and Move.
By encoding the choice of leaving the source untouched (`Copy`) and invalidating it (`Move`) in MIR, we can express moves of copyable values and have MIR borrow-checking enforce them, *including* ownership transfer of stack locals in calls (when the ABI passes by indirection).
Optimizations could turn a "last-use" `Copy` into a `Move`, and the MIR borrow-checker, at least within the confines of safe code, could even do this when the underlying lvalue was borrowed.
(However, that last part would be the first time lifetime inference affects code generation, AFAIK).
Furthermore, as `Move`s invalidate borrows as well, for any local that is initialized only once, we can ignore borrows that happened before a `Move` and safely reuse/replace its memory storage.
This will allow us to perform NRVO in the presence of short-lived borrows, unlike LLVM (currently), and even compute optimal `StorageLive...StorageDead` ranges instead of discarding them.
[auto-toolstate][1/8] Always ignore build failure of failable tools (rls, rustfmt, clippy)
If build failed for these tools, they will be automatically skipped from distribution, and will not fail the whole build.
Test failures are *not* ignored, nor build failure of other tools (e.g. cargo). Therefore it should have no observable effect to the current CI system.
This is step 1/8 of automatic management of broken tools #45861. The purpose is concentrate all failure detection about tools into a single CI job for easy management, while keeping the ability to distribute these tools in the nightlies.
r? @Mark-Simulacrum
Document non-obvious behavior of fmt::UpperHex & co for negative integers
Before stabilization I’d have suggested changing the behavior, but that time is past.
Introduce LinkedList::drain_filter
This introduces `LinkedList::remove_if`.
This operation embodies one of the use-cases where `LinkedList` would typically be preferred over `Vec`: random removal and retrieval.
There are a number of considerations with this:
Should there be two `remove_if` methods? One where elements are only removed, one which returns a collection of removed elements.
Should this be implemented using a draining iterator pattern that covers both cases? I suspect that would incur a bit of overhead (moving the element into the iterator, then into a new collection). But I'm not sure. Maybe that's an acceptable compromise to maximize flexibility.
I don't feel I've had enough exposure to unsafe programming in rust to be certain the implementation is correct. This relies quite heavily on moving around copies of Shared pointers to make the code reasonable. Please help me out :).
Remove semicolon note
In reference to issue #46186
r? @estebank
First time doing a pull request, if there are any suggestions on how to improve this please let me know.
@jjolly
MIR: Fix value moved diagnose messages
#45960. I believe this will take a different approach. Simply replacing all nouns to verbs (`desired_action`) messes up the message `use of moved value` (although fixes the message in original issue). Here is what happens:
<pre>
$ rustc -Zborrowck-mir src/test/ui/borrowck/borrowck-reinit.rs
error[E0382]: <b>used</b> of moved value: `x` (Mir)
--> src/test/ui/borrowck/borrowck-reinit.rs:18:16
|
17 | drop(x);
| - value moved here
18 | let _ = (1,x);
| ^ value used here after move
error: aborting due to 2 previous errors
</pre>
(Notice: *"**used** of moved value: `x`"* instead of *"**use**"*)
Which does not seem to be okay.
After experimenting a bit, it looks like [`report_use_of_moved_value()`](1dc0b573e7/src/librustc_mir/borrow_check.rs (L1319)) tries to handle both these messages by taking in only one form of`desired_action`.
These messages rise from: *"[{noun} of moved value](1dc0b573e7/src/librustc_mir/borrow_check.rs (L1338-L1342))"* and *"[value {verb} here after move](1dc0b573e7/src/librustc_mir/borrow_check.rs (L1343))"*.
This PR fixes *"value {verb} here after move"* type messages by passing a corresponding verb (`desired_action`) instead of the original noun.
Stabilize spin_loop_hint
Stabilize `spin_loop_hint` in release `1.23.0`.
I've also renamed feature `hint_core_should_pause` to `spin_loop_hint`.
cc #41196
Implement From<RecvError> for TryRecvError and RecvTimeoutError
According to the documentation, it looks to me that `TryRecvError` and `RecvTimeoutError` are strict extensions of `RecvError`. As such, it makes sense to allow conversion from the latter type to the two former types without constraining future developments.
This permits to write `input.recv()?` and `input.recv_timeout(timeout)?` in the same function for example.
Mir Borrowck: Parity with Ast for E0384 (Cannot assign twice to immutable)
- Closes#45199
- Don't allow assigning to dropped immutable variables
- Show the "first assignment" note on the first assignment that can actually come before the second assignment.
- Make "first assignment" notes point to function parameters if needed.
- Don't show a "first assignment" note if the first and second assignment have the same span (in a loop). This matches ast borrowck for now, but maybe this we should add "in previous loop iteration" as with some other borrowck errors. (Commit 2)
- Use revisions to check mir borrowck for the existing tests for this error. (Commit 3)
~~Still working on a less ad-hoc way to get 'first assignment' notes to show on the correct assignment. Also need to check mutating function arguments.~~ Now using a new dataflow pass.
Make accesses to fields of packed structs unsafe
To handle packed structs with destructors (which you'll think are a rare
case, but the `#[repr(packed)] struct Packed<T>(T);` pattern is
ever-popular, which requires handling packed structs with destructors to
avoid monomorphization-time errors), drops of subfields of packed
structs should drop a local move of the field instead of the original
one.
That's it, I think I'll use a strategy suggested by @Zoxc, where this mir
```
drop(packed_struct.field)
```
is replaced by
```
tmp0 = packed_struct.field;
drop tmp0
```
cc #27060 - this should deal with that issue after codegen of drop glue
is updated.
The new errors need to be changed to future-compatibility warnings, but
I'll rather do a crater run first with them as errors to assess the
impact.
cc @eddyb
Things which still need to be done for this:
- [ ] - handle `repr(packed)` structs in `derive` the same way I did in `Span`, and use derive there again
- [ ] - implement the "fix packed drops" pass and call it in both the MIR shim and validated MIR pipelines
- [ ] - do a crater run
- [ ] - convert the errors to compatibility warnings
mention nightly in -Z external-macro-backtrace note
Fix#46167 by mentioning that you need nightly in the message that tells you to pass `-Z external-macro-backtrace`.
Rationale:
1. The reason for having this message is to increase discoverability of the functionality. If the message is only shown on nightly it's less disoverable.
2. The same approach is taken if you call a const fn in const context without its feature gate (previously, if you called it without `#![feature(const_fn)]`).
cc @kennytm
