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
I don't really understand what it's for, but see the comment here:
https://github.com/rust-lang/rust/pull/50173#discussion_r204222336
where arielb1 said
> Does this check do anything these days? I think `$0: Trait` is always considered ambiguous
and nikomatsakis agreed we may be able to get rid of it
If object-safety checks succeed for a receiver type, make sure the
receiver’s abi is
a) a Scalar, when Self = ()
b) a ScalarPair, when Self = dyn Trait
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.
For now, all of the receivers that we care about are just a newtyped
pointer — i.e. `Box<Self>`, `Rc<Self>`, `Pin<Box<Self>>`, `Pin<&mut
Self>`. This is much simpler to implement in codeine than the more
general case, because the ABI is the same as a pointer. So we add some
checks in typeck/coherence/builtin.rs to make sure that implementors of
CoerceSized are just newtyped pointers. In this commit, we also
implement the codegen bits.
For a trait method to be considered object-safe, the receiver type must
satisfy certain properties: first, we need to be able to get the vtable
to so we can look up the method, and second, we need to convert the
receiver from the version where `Self=dyn Trait`, to the version where
`Self=T`, `T` being some unknown, `Sized` type that implements `Trait`.
To check that the receiver satisfies those properties, we use the
following query:
forall (U) {
if (Self: Unsize<U>) {
Receiver[Self => U]: CoerceSized<Receiver>
}
}
where `Receiver` is the receiver type of the method (e.g. `Rc<Self>`),
and `Receiver[Self => U]` is the receiver type where `Self = U`, e.g.
`Rc<U>`.
forall queries like this aren’t implemented in the trait system yet, so
for now we are using a bit of a hack — see the code for explanation.
This trait is more-or-less the reverse of CoerceUnsized, and will be
used for object-safety checks. Receiver types like `Rc` will have to
implement `CoerceSized` so that methods that use `Rc<Self>` as the
receiver will be considered object-safe.
The `thread_local!` macro delegated to an internal macro but it didn't
do so in a macros-and-the-module-system compatible fashion, meaning if a
`#![no_std]` crate imported `std` and tried to use `thread_local!` it
would fail due to missing a lookup of an internal macro.
This commit switches the macro to instead use `$crate` to invoke other
macros, ensuring that it'll work when `thread_local!` is imported alone.
Some code in the TLS implementation in libstd stores `Some(val)` into an
`&mut Option<T>` (effectively) and then pulls out `&T`, but it currently
uses `.unwrap()` which can codegen into a panic even though it can never
panic. With sufficient optimizations enabled (like LTO) the compiler can
see through this but this commit helps it along in normal mode
(`--release` with Cargo by default) to avoid codegen'ing the panic path.
This ends up improving the optimized codegen on wasm by ensuring that a
call to panic pulling in more file size doesn't stick around.
Rollup of 13 pull requests
Successful merges:
- #55280 (Add libproc_macro to rust-src distribution)
- #55469 (Regression tests for issue #54477.)
- #55504 (Use vec![x; n] instead of iter::repeat(x).take(n).collect())
- #55522 (use String::from() instead of format!() macro to construct Strings.)
- #55536 (Pass suggestions as impl Iterator instead of Vec)
- #55542 (syntax: improve a few allocations)
- #55558 (Tweak `MatcherPos::matches`)
- #55561 (Fix double_check tests on big-endian targets)
- #55573 (Make sure the `aws` executable is in $PATH on macOS)
- #55574 (Use `SmallVec` within `MoveData`.)
- #55575 (Fix invalid_const_promotion test on some archs)
- #55578 (Made doc example of `impl Default for …` use `-> Self` instead of explicit self type)
- #55582 (Remove unused import copy from publish_toolstate.py)
Fix double_check tests on big-endian targets
Since the enums get optimized down to 1 byte long, the bits set in the `usize` member don't align with the `enum` values on big-endian machines. Avoid this issue by shrinking the integer member to the
same size as the enums.
Instead, pass the environment to execvpe, so the kernel can apply it directly to the new process. This avoids a use-after-free in the case where exec'ing the new process fails for any reason, as well as a race condition if there are other threads alive during the exec.
Regression tests for issue #54477.
At some point someone may want to revisit PR #53564
it would be really good to have regression tests for #54477 before that happens. :)
