This is a variant of `ui/borrowck/borrowck-closures-mut-of-imm.rs`
that I used to help identify what changes I needed to make to the
latter file in order to recover its instances of E0524 under NLL.
(Basically this test includes the changes you'd need to make to
`ui/borrowck/borrowck-closures-mut-of-imm.rs` in order to get rid of
occurrences of E0596. And then I realized that one needs to add
invocations of the closures in order to properly extend the mutable
reborrows in a manner such that NLL will roughly match AST-borrowck.)
This is based on the feedback from estebank:
"""
I believe that test can be removed outright. It'd be impossible for a
new change to go through that breaks this kind of output without it
being picked up by multiple other `stderr` tests. This is an artifact
of the transition period to the "new" output style.
"""
see: https://github.com/rust-lang/rust/issues/52663#issuecomment-422155551
This is not strictly necessary to make this test "more robust with
respect to NLL"; its just an attempt to narrow the scope of the test
and focus on its core.
Most of the time we want to robustify tests, but in this case this
test is deliberately encoding artifacts of AST-borrowck. So instead
of adding artificial uses that would obscure the aspects of
AST-borrowck that are being tests, we instead use revisions and then
mark the cases that apply to NLL as well as AST-borrowck.
The error message is sub-par, but fixing that requries moving ScalarMaybeUndef
to librustc which would conflict badly with another PR that is in flight.
In each of the three cases in this test, there is a mutable borrow
of some field of the union and then a shared borrow of some other field
immediately following.
Under NLL, the mutable borrow is killed straight away as it isn't
used later - therefore not causing a conflict with the shared borrow.
This commit adds a use of the first mutable borrow to force the intended
errors to appear under NLL.
This commit makes two changes:
First, it updates the dataflow builder to add an init for the place
containing a union if there is an assignment into the field of
that union.
Second, it stops a "use of uninitialized" error occuring when there is an
assignment into the field of an uninitialized union that was previously
initialized. Making this assignment would re-initialize the union, as
tested in `src/test/ui/borrowck/borrowck-union-move-assign.nll.stderr`.
The check for previous initialization ensures that we do not start
supporting partial initialization yet (cc #21232, #54499, #54986).
Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types
This replaces #50173. Over the months that that PR was open, we made a lot of changes to the way this was going to be implemented, and the long, meandering comment thread and commit history would have been confusing to people reading it in the future. So I decided to package everything up with new, straighforward commits and open a new PR.
Here are the main points. Please read the commit messages for details.
- To simplify codegen, we only support receivers that have the ABI of a pointer. That means they are builtin pointer types, or newtypes thereof.
- We introduce a new trait: `DispatchFromDyn<T>`, similar to `CoerceUnsized<T>`. `DispatchFromDyn` has extra requirements that `CoerceUnsized` does not: when you implement `DispatchFromDyn` for a struct, there cannot be any extra fields besides the field being coerced and `PhantomData` fields. This ensures that the struct's ABI is the same as a pointer.
- For a method's receiver (e.g. `self: Rc<Self>`) to be object-safe, it needs to have the following property:
- let `DynReceiver` be the receiver when `Self = dyn Trait`
- let `ConcreteReceiver` be the receiver when `Self = T`, where `T` is some unknown `Sized` type that implements `Trait`, and is the erased type of the trait object.
- `ConcreteReceiver` must implement `DispatchFromDyn<DynReceiver>`
In the case of `Rc<Self>`, this requires `Rc<T>: DispatchFromDyn<Rc<dyn Trait>>`
These rules are explained more thoroughly in the doc comment on `receiver_is_dispatchable` in object_safety.rs.
r? @nikomatsakis and @eddyb
cc @arielb1 @cramertj @withoutboats
Special thanks to @nikomatsakis for getting me un-stuck when implementing the object-safety checks, and @eddyb for helping with the codegen parts.
EDIT 2018-11-01: updated because CoerceSized has been replaced with DispatchFromDyn
rustc: improve E0669 span
E0669 refers to an operand that cannot be coerced into a single LLVM
value, unfortunately right now this uses the Span for the entire inline
assembly statement, which is less than ideal.
This commit preserves the Span from HIR, which lets us emit the error
using the Span for the operand itself in MIR.
r? @nagisa
cc/ @parched
universes refactor 3
Some more refactorings from my universe branch. These are getting a bit more "invasive" -- they start to plumb the universe information through the canonicalization process. As of yet though I don't **believe** this branch changes our behavior in any notable way, though I'm marking the branch as `WIP` to give myself a chance to verify this.
r? @scalexm
disallow `#[repr(C)] and `#[repr(packed)]` on structs implementing DispatchFromDyn because they will change the ABI from Scalar/ScalarPair to Aggregrate, resulting in an ICE during object-safety checks or codegen
Rename `CoerceSized` to `DispatchFromDyn`, and reverse the direction so that, for example, you write
```
impl<T: Unsize<U>, U> DispatchFromDyn<*const U> for *const T {}
```
instead of
```
impl<T: Unsize<U>, U> DispatchFromDyn<*const T> for *const U {}
```
this way the trait is really just a subset of `CoerceUnsized`.
The checks in object_safety.rs are updated for the new trait, and some documentation and method names in there are updated for the new trait name — e.g. `receiver_is_coercible` is now called `receiver_is_dispatchable`. Since the trait now works in the opposite direction, some code had to updated here for that too.
I did not update the error messages for invalid `CoerceSized` (now `DispatchFromDyn`) implementations, except to find/replace `CoerceSized` with `DispatchFromDyn`. Will ask for suggestions in the PR thread.
I’m not sure why these tests have different output now, but they do.
In all cases, the error message that is missing looks like this: “the
trait bound `dyn Trait: Trait` is not satisfied”
My guess is that the error message is going away because object-safety
now involves trait solving, and these extra error messages are no
longer leaking out.
Since the enums get optimized down to 1 byte long, the bits
set in the usize member don't align with the enums on big-endian
machines. Avoid this issue by shrinking the integer member to the
same size as the enums.
