expand: Add error check if derive has wrong item

[Pasta-coder]

The DeriveVisitor previously dispatched calls to specific handlers (like DeriveClone) without validating the input item type. This caused internal compiler errors (ICEs) when users attempted to derive traits on invalid items like functions or traits, as the handlers assumed the input was a struct, enum, or union.

This patch adds a validation predicate to the DeriveVisitor to reject invalid items gracefully with a diagnostic error before dispatching.

Fixes #3875

gcc/rust/ChangeLog:

* expand/rust-derive.h: Add validate_item prototype.
* expand/rust-derive.cc (DeriveVisitor::derive): Use visitor validation.
(DeriveVisitor::validate_item): New function to check item kind.

gcc/testsuite/ChangeLog:

* rust/compile/derive-on-invalid-item.rs: New test.

• GCC development requires copyright assignment or the Developer's Certificate of Origin sign-off, see https://gcc.gnu.org/contribute.html or https://gcc.gnu.org/dco.html
• Read contributing guidlines
• make check-rust passes locally
• Run clang-format
• Added any relevant test cases to gcc/testsuite/rust/

[dkm]

Hello, thanks for your contribution!

Small nitpick on the Changelog part...

* expand/rust-derive.h: Add validate_item prototype.

Does not target a specific "item". You could be more precise using:

* expand/rust-derive.h (DeriveVisitor::validate_item): New.

[Pasta-coder]

@dkm hello,

commit message regarding changelog changed .

thanks

[Pasta-coder]

I realized there might be a potential false positive with Tuple Structs (e.g., struct Foo(i32);).

If AST::Item::Kind differentiates between named Structs and TupleStructs, my current whitelist might incorrectly reject valid tuple structs.

I am going to verify this locally by adding a test case for a tuple struct. If it fails, I will update validate_item to explicitly include Kind::TupleStruct and push the fix along with the test.

[dkm]

@dkm hello,

commit message regarding changelog changed .

thanks

Thanks!

[Pasta-coder]

@dkm hello,

I reverted the extra Kind check since TupleStruct falls under Kind::Struct. I kept the test case to verify that tuple structs are correctly accepted.

Open for review .

thankyou

[Pasta-coder]

@P-E-P please review .

thankyou .

[Pasta-coder]

@CohenArthur please review .

thankyou .

[P-E-P]

I don't really get what this PR brings on the table. Sure there is a new fancy helper function, but it has a side effect, we're emitting an error. Moving the error out of that helper means it becomes so short a function may not even be worth it anymore.

The check was already there so we didn't get anything from that.

We do get a new test which is a bit more complete compared to rust/compile/issue-3971.rs.

Am I missing something ?

[Pasta-coder]

introducing helper function does have a side effect .

why i did what i did ? the ICE was solved in #4211 but issue #3875 was still open with comments suggesting a helper function , also test was missing TupleStructs check . so , i opened a pr .

1. should i remove the helper function or return bool from helper and emit error from caller ? (do you prefer such helpers?)
2. or should this pr be solely for adding a new test ?

thankyou

[P-E-P]

introducing helper function does have a side effect .

why i did what i did ? the ICE was solved in #4211 but issue #3875 was still open with comments suggesting a helper function , also test was missing TupleStructs check . so , i opened a pr .

1. should i remove the helper function or return `bool` from helper and emit error from caller ? (do you prefer such helpers?)

2. or should this pr be solely for adding a new test ?

thankyou

I think we should definitely keep the test, but I wouldn't keep the rest of the changes.

[Pasta-coder]

@P-E-P no this pr only adds the test .

thankyou.

[P-E-P]

I wonder, maybe you could remove those dg-excess-errors if you declare Clone. Have you tried putting those traits ?

Suggested change

	fn foo() {} // { dg-excess-errors "" }
	#![feature(lang_items)]
	fn foo() {}
	#[lang = "sized"]
	pub trait Sized {}
	#[lang = "clone"]
	pub trait Clone: Sized {}

Excess errors should usually be avoided as they'll catch any errors, and this means that if the compiler's behavior change in the future they won't catch an error change and things may break silently.