Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add trait_upcasting related languages changes #1259

Closed
wants to merge 2 commits into from
Closed

Add trait_upcasting related languages changes #1259

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
89df289
Add trait_upcasting related languages changes
crlf0710 Sep 2, 2022
75d48ad
Address review comments.
crlf0710 Nov 22, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions src/behavior-considered-undefined.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Member

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:

Invalid metadata in a wide reference, `Box<T>`, or raw pointer

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

Copy link
Member

Choose a reason for hiding this comment

The 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
Expand Down
4 changes: 3 additions & 1 deletion src/type-coercions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Member

Choose a reason for hiding this comment

The 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.


Expand All @@ -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 `T` has `U` as one of its ancestor trait.
crlf0710 marked this conversation as resolved.
Show resolved Hide resolved

* `Foo<..., T, ...>` to `Foo<..., U, ...>`, when:
* `Foo` is a struct.
* `T` implements `Unsize<U>`.
Expand Down