Skip to content

Introduce CoercePointeeValidated for coherence checks at typeck stage#136107

Merged
bors merged 6 commits intorust-lang:masterfrom
dingxiangfei2009:coerce-pointee-wellformed
Feb 11, 2025
Merged

Introduce CoercePointeeValidated for coherence checks at typeck stage#136107
bors merged 6 commits intorust-lang:masterfrom
dingxiangfei2009:coerce-pointee-wellformed

Conversation

@dingxiangfei2009
Copy link
Copy Markdown
Contributor

Fix #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. CoercePointee leaks unstable unsizing impls #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.
  2. 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

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

F-derive_coerce_pointee Feature: RFC 3621's oft-renamed implementation S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CoercePointee doesn't tightly enforce the restriction to #[repr(transparent)]-only wrappers, if other proc-macros are involved

6 participants