-
Notifications
You must be signed in to change notification settings - Fork 492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add trait_upcasting related languages changes #1259
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -34,6 +34,7 @@ code. | |
* Invoking undefined behavior via compiler intrinsics. | ||
* Executing code compiled with platform features that the current platform | ||
does not support (see [`target_feature`]), *except* if the platform explicitly documents this to be safe. | ||
* Performing non-nop coercion on a dangling or unaligned raw pointer. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Though now that I read this, I think this should be clarified though to integrate language which more precisely reflects the decision in rust-lang/rust#101336. Specifically, should we mention that the vtable pointer needs to point to a valid vtable? |
||
* Calling a function with the wrong call ABI or unwinding from a function with the wrong unwind ABI. | ||
* Producing an invalid value, even in private fields and locals. "Producing" a | ||
value happens any time a value is assigned to or read from a place, passed to | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -159,7 +159,7 @@ Coercion is allowed between the following types: | |
### Unsized Coercions | ||
|
||
The following coercions are called `unsized coercions`, since they | ||
relate to converting sized types to unsized types, and are permitted in a few | ||
relate to converting types to unsized types, and are permitted in a few | ||
cases where other coercions are not, as described above. They can still happen | ||
anywhere else a coercion can occur. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMO it is worth stating explicitly that "unsizing" is a misnomer now and this also covers coercions from unsized types to unsized types. |
||
|
||
|
@@ -172,6 +172,8 @@ an implementation of `Unsize<U>` for `T` will be provided: | |
|
||
* `T` to `dyn U`, when `T` implements `U + Sized`, and `U` is [object safe]. | ||
|
||
* `dyn T` to `dyn U`, when `U` is one of `T`'s supertraits. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should also mention that upcasting coercions allow dropping auto traits. i.e. |
||
|
||
* `Foo<..., T, ...>` to `Foo<..., U, ...>`, when: | ||
* `Foo` is a struct. | ||
* `T` implements `Unsize<U>`. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not exactly clear why this is being added in this PR, since I can't find any reference to it related to RFC 3324. Can you say more about why this is being added? Is there some context here?
cc @RalfJung since you often know about UB stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it was decided in a T-lang FCP in rust-lang/rust#101336, the stabilization of trait_upcasting just becomes the first time that this behavior can be exercised, as far as I recall.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My expectation was that it is completely okay for the pointer itself to be dangling or unaligned; only the vtable must be valid. And we already require the vtable to be valid; we say it is UB when one creates the following:
So I don't think any change is needed to the UB list. At least I highly doubt we want to require the data part of the wide raw pointer to be valid in any way for such a coercion.
Cc @rust-lang/opsem