no_coverage feature-gated on function, not crate?

[Mark-Simulacrum]

It looks like the no_coverage attribute was added by checking for feature(no_coverage) on the function, but this isn't how feature gating usually works. Additionally, I don't believe that restricts usage of this on stable/beta, since nothing is actually checking this feature gate.

Noticed based on the test case (https://github.com/rust-lang/rust/blob/master/src/test/ui/feature-gates/feature-gate-no_coverage.rs) and while looking at the feature-gating code.

cc @tmandry @richkadel

[Mark-Simulacrum]

cc #84605

[richkadel]

It looks like the no_coverage attribute was added by checking for feature(no_coverage) on the function, but this isn't how feature gating usually works.

Correct. The driving reason for adding the feature was to resolve #83601, and that issue occurred because core/std pushes a hidden function into everything that derives Eq, and we need to hide that function (from coverage instrumentation). So the only way to gate the issue at the crate level would be to automatically enable the feature in any crate that derives Eq (which is just about every crate).

Feature gating at the function level resolved the problem, even though it was non-standard.

I do allow feature-gating at the crate level as well, but it's not used by Eq.

Additionally, I don't believe that restricts usage of this on stable/beta, since nothing is actually checking this feature gate.

I didn't realize this also needs to be checked. Is there an example of how to do this, so I can also implement it in the function-based feature-gate check?

[Mark-Simulacrum]

It should be possible to adjust the normal feature gating to correctly handle macro expanded sources - that is, allow the built-in derives to generate it without it being stabilized. We do this for the Structural trait impls somehow, for example; possibly enough to set the span appropriately. If necessary, I can either provide or track down someone who can, further hints. It might be good to look at how the structural equality worked before the move to the trait impls as it had a similar built-in attribute.

In the meantime we'll likely revert the PR on just branched beta (1.53) so we don't accidentally stabilize the feature.

[richkadel]

@Mark-Simulacrum: I just uploaded a PR to fix this, as an alternative to reverting: #84871

Your call.

Thanks!