Limit when future incompatibility reports are displayed

[Michael-F-Bryan]

Problem

Imagine you are working on a project with a dependency tree that has several layers.

• my-crate
  • direct-dependency v0.1.2
    • transitive-dependency v1.2.0

If transitive-dependency v1.2.0 triggers a future incompatibility report, anyone trying to build it will be shown a warning. This is super useful because it lets users know they need to update their dependencies to avoid potential compile errors in the future.

However, the author of my-crate has no direct control over which version of transitive-dependency is used. That means they now get presented with a warning on every single build that they can't resolve, which is a really bad developer experience.

One might argue that this provides pressure to fix/upgrade the offending dependency, but in practice most people won't have the time to make a PR to transitive-dependency that fixes the issue, wait for it to be merged and released, then make another PR to direct-dependency that updates their Cargo.toml to require the correct version. Even if people do have the time/energy to go through this process, it requires the upstream crate to merge/release PRs in a timely manner. One example of this is the fs-extra crate which had an unreleased future incompatibility fix for almost 2 years (see tikv/jemallocator#46) and has been triggering warnings on beta/nightly for a couple weeks.

That means you end up with a) users being spammed with warnings every time they build their code and being trained to ignore build warnings, or b) users setting [future-incompat-report] frequency = "always" in their $HOME/.cargo/config.toml and negating the point of having future incompatibility reports in the first place.

You see a similar issue in the NPM ecosystem where creating a new React app with yarn create react-app bombards the user with a dozen warnings that they have no way of resolving.

Proposed Solution

There are two solutions I can think of.

The first solution is to change the future incompatibility warnings so they are only be shown for direct dependencies. That will let the developers that have control over the offending dependency resolve the problem while not spamming the rest of the ecosystem.

The second solution is similar to the first, except we make it configurable. Besides frequency = "always" and frequency = "never", we would introduce DirectDependency and Once variants to the CargoFutureIncompatFrequencyConfig enum. This would alter the logic to only show warnings for direct dependencies (as above) or the first time that crate is built¹.

Notes

No response

Footnotes

1. There are a number of ways we could do this, but the easiest is probably to track which warnings have already been displayed by adding a file to target/. ↩

[Eh2406]

Before I get into details, we have always planned to add some way to reduce the noise of future incompatibility warnings.

Even if people do have the time/energy to go through this process, it requires the upstream crate to merge/release PRs in a timely manner. One example of this is the fs-extra crate which had an unreleased future incompatibility fix for almost 2 years (see tikv/jemallocator#46) and has been triggering warnings on beta/nightly for a couple weeks.

A crate that does not fix future incompatibility warnings for two years is best described as unmaintained. (If it's a false positive, file an issue with Rustc. Part of the social contract of future incompatibility warnings is that they don't have false positives.) It is expected that after some time as a future incompatibility warning it will just become a compiler error. If we normalize people ignoring future incompatibility warnings, their users will just get compiler errors instead.

Of course, spamming many messages all the time is one way to convince people to ignore the messages.

[dtantsur]

This is quite an annoying problem for me since these compatibility warnings (in my case for rustc-serialize which I don't depend on) show as errors in my ViM error window. Always, with no way to opt-out.