Don't allow the #[pointee] attribute where it doesn't belong

[Brezak]

Error if the #[pointee] attribute is applied to anything but generic type parameters.

Closes #128485
Related to #123430

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pnkfelix (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[Darksonn]

@rustbot label F-derive_smart_pointer

[oli-obk]

This still allows type Foo<#[pointee] T> = T; I think? It should only be legal below a smart pointer derive. Maybe check how derive(Default) handles the default enum variant attribute

[Darksonn]

PR #128925 was opened to fix #128888, but it may also have fixed the issue this PR is trying to fix.

[Brezak]

This PR also adds a check that [#pointee] is only attached to a generic parameter. Should I reduce this PR to just that, or close it and open a new one?

[Darksonn]

That change could still make sense.

[bors]

☔ The latest upstream changes (presumably #129202) made this pull request unmergeable. Please resolve the merge conflicts.

[Brezak]

I've shrunk the PR down to just checking if the attribute is applied to a generic type parameter.

[bors]

☔ The latest upstream changes (presumably #129721) made this pull request unmergeable. Please resolve the merge conflicts.

[pnkfelix]

Hmm.

Technically I think you still need to ensure you recur into the default: &Option<P<Ty>> that's held within that enum payload above.

I think the below is the kind of case you need to worry about that motivates recurring here:

struct SomeStruct<'a, T = [u32; const { #[pointee] struct UhOhYetAnotherTypeDefn<U>; 10 }]> { ... }

(Yes its a corner case.)

[pnkfelix]

You can model the recursion you need to do by looking at walk_generic_param, and just leaving out the visit_attribute part:

rust/compiler/rustc_ast/src/visit.rs

Lines 749 to 767 in c39f318

	pub fn walk_generic_param<'a, V: Visitor<'a>>(
	visitor: &mut V,
	param: &'a GenericParam,
	) -> V::Result {
	let GenericParam { id: _, ident, attrs, bounds, is_placeholder: _, kind, colon_span: _ } =
	param;
	walk_list!(visitor, visit_attribute, attrs);
	try_visit!(visitor.visit_ident(*ident));
	walk_list!(visitor, visit_param_bound, bounds, BoundKind::Bound);
	match kind {
	GenericParamKind::Lifetime => (),
	GenericParamKind::Type { default } => visit_opt!(visitor, visit_ty, default),
	GenericParamKind::Const { ty, default, kw_span: _ } => {
	try_visit!(visitor.visit_ty(ty));
	visit_opt!(visitor, visit_anon_const, default);
	}
	}
	V::Result::output()
	}

[Brezak]

I've fixed the edge case. As a comment in the new code mentions we end up rejecting valid code like:

#![feature(derive_smart_pointer)]
use std::marker::SmartPointer;
#[derive(SmartPointer)]
#[repr(transparent)]
struct Weird<
    'a,
    T: ?Sized,
    const V: u32 = {
        #[derive(SmartPointer)]
        #[repr(transparent)]
        struct UhOh<'b, #[pointee] X: ?Sized>(&'b X);
        10
    },
> {
    ptr: &'a T,
}

Handling this properly isn't possible in the generic case since we can't know if the inner derive is actually a different trait with the same name. Given how unlikely the whole scenario is I've decided to go ahead with the changes anyway.

[pnkfelix]

@rustbot author

[Brezak]

@rustbot review

[pnkfelix]

@bors r+ rollup

[bors]

📌 Commit aa4f16a has been approved by pnkfelix

It is now in the queue for this repository.