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.

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

CoercePointee leaks unstable unsizing impls #135217

Closed
BoxyUwU opened this issue Jan 7, 2025 · 2 comments · Fixed by #137728
Closed

CoercePointee leaks unstable unsizing impls #135217

BoxyUwU opened this issue Jan 7, 2025 · 2 comments · Fixed by #137728
Assignees
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.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 10, 2025
…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
…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
…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
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
bors added a commit to rust-lang-ci/rust that referenced this issue Feb 27, 2025
Remove unsizing coercions for tuples

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

Tracking issue: rust-lang#42877
Fixes: rust-lang#135217
@Darksonn
Copy link
Contributor

Darksonn commented Mar 5, 2025

@rustbot claim

@rustbot rustbot assigned Darksonn and unassigned compiler-errors Mar 5, 2025
@bors bors closed this as completed in 257b494 Mar 5, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Mar 5, 2025
Rollup merge of rust-lang#137728 - Darksonn:no-tuple-unsize, r=oli-obk

Remove unsizing coercions for tuples

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

Tracking issue: rust-lang#42877
Fixes: rust-lang#135217
github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this issue Mar 11, 2025
…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
github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this issue Mar 11, 2025
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Development

Successfully merging a pull request may close this issue.

4 participants