Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

CoercePointee leaks unstable unsizing impls #135217

Open
BoxyUwU opened this issue Jan 7, 2025 · 1 comment · May be fixed by #137728
Open

CoercePointee leaks unstable unsizing impls #135217

BoxyUwU opened this issue Jan 7, 2025 · 1 comment · May be fixed by #137728
Assignees
@compiler-errors
Labels
A-coercions Area: implicit and explicit `expr as Type` coercions F-derive_coerce_pointee Feature: RFC 3621's oft-renamed implementation T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@BoxyUwU
Copy link
Member

BoxyUwU commented Jan 7, 2025 

#![feature(derive_coerce_pointee)]
use std::marker::PhantomData;
use std::marker::CoercePointee; 
#[derive(CoercePointee)] #[repr(transparent)]
struct MyPointer<'a, T, #[pointee] U: ?Sized> {
    ptr: &'a (T, U),
}

fn main() {
    let x = MyPointer { ptr: &(1u32, 1u32) };
    let _: MyPointer<u32, dyn Send> = x;
}

Originally posted by @lcnr in #133820 (comment)
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jan 7, 2025
@BoxyUwU BoxyUwU added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-coercions Area: implicit and explicit `expr as Type` coercions T-types Relevant to the types team, which will review and decide on the PR/issue. F-derive_coerce_pointee Feature: RFC 3621's oft-renamed implementation and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Jan 7, 2025
@compiler-errors compiler-errors self-assigned this Jan 7, 2025
@compiler-errors
Copy link
Member

I'll take a stab at this.

@ojeda ojeda mentioned this issue Jan 7, 2025
Open
90 tasks
@Darksonn Darksonn mentioned this issue Jan 16, 2025
Closed
@dingxiangfei2009 dingxiangfei2009 mentioned this issue Jan 26, 2025
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 10, 2025
@matthiaskrgr
Rollup merge of rust-lang#136107 - dingxiangfei2009:coerce-pointee-we…
fa8158a 
…llformed, r=compiler-errors

Introduce CoercePointeeWellformed for coherence checks at typeck stage

Fix rust-lang#135206

This is the first PR to introduce the "wellformedness" check for `derive(CoercePointee)`.

This patch introduces a new error code to cover all the prerequisites of the said macro. The checks that is enforced with this patch is whether the data is indeed `struct` and whether the layout is set to `repr(transparent)`.

A following series of patch will arrive later to address the following concern.
1. rust-lang#135217 so that we would only admit one single coercion on one type parameter, and leave the rest for future consideration in tandem of development of other coercion rules.
1. Enforcement of data field requirements.

**An open question** is whether there is a good schema to encode the `#[pointee]` as well, so that we could also check if the `#[pointee]` type parameter is indeed `?Sized`.

`@rustbot` label F-derive_coerce_pointee
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 10, 2025
@matthiaskrgr
Rollup merge of rust-lang#136107 - dingxiangfei2009:coerce-pointee-we…
ebdf4b0 
…llformed, r=compiler-errors

Introduce CoercePointeeWellformed for coherence checks at typeck stage

Fix rust-lang#135206

This is the first PR to introduce the "wellformedness" check for `derive(CoercePointee)`.

This patch introduces a new error code to cover all the prerequisites of the said macro. The checks that is enforced with this patch is whether the data is indeed `struct` and whether the layout is set to `repr(transparent)`.

A following series of patch will arrive later to address the following concern.
1. rust-lang#135217 so that we would only admit one single coercion on one type parameter, and leave the rest for future consideration in tandem of development of other coercion rules.
1. Enforcement of data field requirements.

**An open question** is whether there is a good schema to encode the `#[pointee]` as well, so that we could also check if the `#[pointee]` type parameter is indeed `?Sized`.

`@rustbot` label F-derive_coerce_pointee
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 11, 2025
@matthiaskrgr
Rollup merge of rust-lang#136107 - dingxiangfei2009:coerce-pointee-we…
af3c51d 
…llformed, r=compiler-errors

Introduce CoercePointeeWellformed for coherence checks at typeck stage

Fix rust-lang#135206

This is the first PR to introduce the "wellformedness" check for `derive(CoercePointee)`.

This patch introduces a new error code to cover all the prerequisites of the said macro. The checks that is enforced with this patch is whether the data is indeed `struct` and whether the layout is set to `repr(transparent)`.

A following series of patch will arrive later to address the following concern.
1. rust-lang#135217 so that we would only admit one single coercion on one type parameter, and leave the rest for future consideration in tandem of development of other coercion rules.
1. Enforcement of data field requirements.

**An open question** is whether there is a good schema to encode the `#[pointee]` as well, so that we could also check if the `#[pointee]` type parameter is indeed `?Sized`.

``@rustbot`` label F-derive_coerce_pointee
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Feb 11, 2025
@rust-timer
Unrolled build for rust-lang#136107
368a423 
Rollup merge of rust-lang#136107 - dingxiangfei2009:coerce-pointee-wellformed, r=compiler-errors

Introduce CoercePointeeWellformed for coherence checks at typeck stage

Fix rust-lang#135206

This is the first PR to introduce the "wellformedness" check for `derive(CoercePointee)`.

This patch introduces a new error code to cover all the prerequisites of the said macro. The checks that is enforced with this patch is whether the data is indeed `struct` and whether the layout is set to `repr(transparent)`.

A following series of patch will arrive later to address the following concern.
1. rust-lang#135217 so that we would only admit one single coercion on one type parameter, and leave the rest for future consideration in tandem of development of other coercion rules.
1. Enforcement of data field requirements.

**An open question** is whether there is a good schema to encode the `#[pointee]` as well, so that we could also check if the `#[pointee]` type parameter is indeed `?Sized`.

``@rustbot`` label F-derive_coerce_pointee
@Darksonn Darksonn linked a pull request Feb 27, 2025 that will close this issue
Open
bors added a commit to rust-lang-ci/rust that referenced this issue Feb 27, 2025
@bors
Auto merge of rust-lang#137728 - Darksonn:no-tuple-unsize, r=<try>
802c9b5 
Remove unsizing coercions for tuples

See rust-lang#42877 (comment) and below comments for justification.

Tracking issue: rust-lang#42877
Fixes: rust-lang#135217
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees

@compiler-errors compiler-errors

Labels
A-coercions Area: implicit and explicit `expr as Type` coercions F-derive_coerce_pointee Feature: RFC 3621's oft-renamed implementation T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Remove unsizing coercions for tuples Darksonn/rust
3 participants
@compiler-errors @BoxyUwU @rustbot