[derive] Don't emit #[cfg(coverage_nightly)]

[joshlf]

As of nightly-2024-11-20 - specifically [1] - this triggers an unexpected_cfgs lint even when emitted in derive-generated code.

[1] rust-lang/rust#132577

Fixes #2117

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.42%. Comparing base (1cc24c0) to head (20f01c4).

Additional details and impacted files

@@           Coverage Diff           @@
##           v0.8.x    #2123   +/-   ##
=======================================
  Coverage   87.42%   87.42%           
=======================================
  Files          16       16           
  Lines        6115     6115           
=======================================
  Hits         5346     5346           
  Misses        769      769           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[joshlf]

Backporting to main in #2126

[taiki-e]

AFAIK, this is the kind of cfg that is set globally on the coverage tool side, so the warning itself is not something we need to be concerned about except that it will break the build if we deny the warning.

Therefore, I wonder if it would be fine to simply allow unexpected_cfg in the generated code.
(See taiki-e/pin-project-lite#33 (comment) for why we believe that generated code should not be expected to be compatible with forbid except for certain lints.)

[joshlf]

AFAIK, this is the kind of cfg that is set globally on the coverage tool side, so the warning itself is not something we need to be concerned about except that it will break the build if we deny the warning.

Therefore, I wonder if it would be fine to simply allow unexpected_cfg in the generated code. (See taiki-e/pin-project-lite#33 (comment) for why we believe that generated code should not be expected to be compatible with forbid except for certain lints.)

I tend to agree that this is bad CI hygiene. However, the benefit to us of using cfg(coverage_nightly) is nearly zero, so we decided to err on the side of unblocking users even if technically those users were assuming too much. But I do agree with your reasoning.