Custom derive attribute stripping is insufficient

[jonas-schievink]

In

#[derive(Derive)]
#[cfg_attr(never, derive(Clone))]
struct S {
    #[cfg(never)]
    invisible_field: u8,
    #[cfg(not(never))]
    visible_field: u8,
}

The Derive macro should be passed the token stream corresponding to

struct S {
    #[cfg(not(never))]
    visible_field: u8,
}

Currently, we pass

#[cfg_attr(never, derive(Clone))]
struct S {
    #[cfg(never)]
    invisible_field: u8,
    #[cfg(not(never))]
    visible_field: u8,
}

Since we have to evalutate cfgs to do this correctly, I propose moving the remove_derive_attrs code to hir_expand.

[jonas-schievink]

Also, we should only be removing #[derive] attributes that come before the currently expanded derive macro, at least when https://github.com/rust-lang/rust/pull/84023 lands (see its tests)

[jonas-schievink]

Another relevant upstream PR: https://github.com/rust-lang/rust/pull/84110

[Arjentix]

Hello! Our team is struggling because of this bug. Do you plan to fix this? It's open for 2 years already.

[silver-ymz]

Same problem. Is there any progress on this issue?

[jeff-hiner]

This got worse for me about 3 or 4 weeks ago, specifically with #[cfg(target_os = ...)] fields. Maybe a regression? It's unfortunately making it impossible to see real errors in VSCode.

[smalis-msft]

Any updates here? This would be a big usability boost IMO.

[izderadicka]

Same (or very similar) problem here with serde derive, it causes no-such-field error , it's caused by field, which is behind inactive feature, line 164,165. If I enable the feature in rust-analyzer settings that it's OK. I'm almost sure that it did work some time ago - few month, so wondering why this old issue demostrated just now.

[ssrlive]

OMG, a three-year-age bug.

[wyatt-herkamp]

I have started implementing a fix for this.

@rustbot claim