ImplGenerics should not emit attributes from generics declaration

[TedDriggs]

On syn@0.13.7, given this input struct from one of darling's examples:

#[derive(FromDeriveInput)]
#[darling(attributes(lorem))]
struct LoremReceiver<#[darling(bound = "::darling::FromGenericParam")] T> {
    generics: ast::Generics<ast::GenericParam<T>>,
}

The compiler produces the following error when trying to run the example:

error[E0658]: The attribute `darling` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
  --> examples/generics.rs:10:10
   |
10 | #[derive(FromDeriveInput)]
   |          ^^^^^^^^^^^^^^^
   |
   = help: add #![feature(custom_attribute)] to the crate attributes to enable
error: aborting due to previous error
For more information about this error, try `rustc --explain E0658`.
error: Could not compile `darling`.

Adding the attribute and running cargo expand produces:

#[darling(attributes(lorem))]
struct LoremReceiver<#[darling(bound = "::darling::FromGenericParam")] T> {
    generics: ast::Generics<ast::GenericParam<T>>,
}

impl<#[darling(bound = "::darling::FromGenericParam")] T: ::darling::FromGenericParam> ::darling::FromDeriveInput for LoremReceiver<T> {
    fn from_derive_input(__di: &::syn::DeriveInput) -> ::darling::Result<Self> {
        // ... remainder elided
    }
}

The compiler appears to be complaining about the attribute in the ImplGeneric position; I've modified my code to strip all attributes from GenericParam before calling split_for_impl and it works fine without the feature flag. This theory is corroborated by rust-lang/rust#48848, which doesn't mention allowing attributes in this position.

I think the fix is as simple as removing this line, though there might be legitimate uses of this I don't know about, maybe?

[dtolnay]

there might be legitimate uses of this I don't know about, maybe?

One legitimate use for attributes in impl generics would be the #[may_dangle] attribute, for example here. Any ideas for how to support both your use case and that one well?

unsafe impl<#[may_dangle] T: ?Sized> Drop for Rc<T> {

[TedDriggs]

Good find - I'd never seen that before. What are the other cases where it can occur? Are doc comments allowed in that position?

Option 1

In that case #[may_dangle] doesn't appear in the declaration of the struct, which is useful. Add a new method, split_decl_for_impl(&self), which has the same behavior as split_for_impl but it tells ImplGenerics not to emit the underlying attributes. It might make sense to deprecate the current method and give the attribute-preserving version a more descriptive name.

Option 2

Have ImplGenerics keep a list of non-custom attrs known to the compiler in that position, and filter out others unless a (currently non-existent) emit_custom_attrs flag is set.

[dtolnay]

I am closing this issue because I would like to see fewer generic parameter attributes in my life. I find the syntax struct S<#[...] T> obtrusive. In darling's case maybe this would work better on two lines the way Serde's bound attribute is represented:

- struct LoremReceiver<#[darling(bound = "::darling::FromGenericParam")] T> {
+ #[darling(bound = "T: darling::FromGenericParam")]
+ struct LoremReceiver<T> {