`derive(CoercePointee)` accepts `?Sized + Sized`

[theemathas]

derive(CoercePointee) checks whether the generic type is ?Sized, and rejects the code if it is not marked as ?Sized. However, making it ?Sized + Sized is still accepted by the macro. That is, the following code compiles:

#![feature(derive_coerce_pointee)]

use std::marker::CoercePointee;

#[derive(CoercePointee)]
#[repr(transparent)]
struct Foo<T: ?Sized + Sized>(*const T);

Is the fact that ?Sized is required effectively just a lint, or is it important for some other reason? Currently, the check doesn't actually enforce anything, and it's possible to accidentally require Sized with something like T: ?Sized + Clone.

Meta

Reproducible on the playground with version 1.93.0-nightly (2025-11-01 bd3ac0330018c23b111b)

[BoxyUwU]

Obscuring the Sized bound behind another trait means I don't think you can actually fix this syntactically

#![feature(derive_coerce_pointee)]

use std::marker::CoercePointee;

trait Trait: Sized {}

#[derive(CoercePointee)]
#[repr(transparent)]
struct Foo<T: ?Sized + Trait>(*const T);

[Darksonn]

Thinking about this, I don't think it's a problem. The macro is effectively useless if Sized is required, but I don't think it causes any issues. I think it's reasonable to say that T: ?Sized is just a form of lint.

[traviscross]

For my part, probably what I'd suggest, then, would be that we should move the syntactic check for T: ?Sized to a deny-by-default lint rather than a hard error. This would let us remove this requirement from our language definition (i.e. from the normative language in the Reference).

[Darksonn]

I can make it a warning, but I'm not sure how to configure that the lint should be deny-by-default since it's declared in the proc-macro, which afaict does lints differently from normal compiler lints. Can you give a hint for how to declare a lint that's deny-by-default and triggered by a macro?

[fmease]

Not saying you should go for it but IMO the most 'proper' approach (contestable) would be to create a new lint and in a late-lint pass look at all structs "that have" #[automatically_derived] CoerceUnsized/DispatchFromDyn/CoercePointeeValidated impls (pick one¹, any or all) or the other way around check impls and look at the self type (whatever is cheaper to compute & more maintainable).

Then you could even check if T semantically requires Sized (in order to account for Sized in supertrait bounds for example) (might be cycle-prone tho, not sure).

That's an expensive approach I'd wager in terms of perf and impl cost.

Footnotes

1. Out of those, CoercePointeeValidated might be sufficient to identify derive(CoercePointee) post expansion. ↩

[Darksonn]

For a lint specific to the macro, this seems the obvious place to detect this:

#[automatically_derived]
impl<T: ?Sized + Sized> ::core::marker::CoercePointeeValidated for MySmartPointer<T> {}

One could also target the other impls. The macro will emit T: Unsize<U> with U: Sized, which will never match any types, so one could try to lint on that too.