Servo has unusual requirements and build systems. I do indeed think Servo is not an average user but I would not suggest they are incredibly rare or some such either.
What I dispute is the assertion that a single de-duplicated message per crate constitutes spam. It would be different if you saw 15 identical warnings of that kind. That would qualify as spam.
As I've noted before, such diagnostic outputs have things you can act on:
File a bug report to upstream or better yet, make a PR.
Bump the version of your crate -- this is often enough to make the error go away.
Temporarily use a patched fork.
But we are not talking about "a slew of warnings". Far from it.
I had read those points and debated about responding to them in my previous message, but opted to keep that message succinct.
So let's address them here.
In the first example of filing a bug report: I think you are conflating taking action with achieving resolution. Of course I agree that it would be good to file a bug upstream: I explicitly mentioned a way to assist with that process in the "Future Work", as you saw. But this does not resolve the diagnostic locally; at least, not until the bug is fixed, the fix is merged, and the crate updated!
Bumping the version of the crate is good, when the option is available and works. Again, the RFC text explicitly points out that we would like to aid in this process. So, no argument there: If it works, that's great.
Using a patched fork may or may not be reasonable, depending on how much effort it takes to fix the problem. (I view using a patched fork as similar to making a PR, in terms of effort expended versus long-term payoff.)
But in any case, I think you are underestimating the effort involved to reach "resolution" for the diagnostics, except for the case of version-bumping. We are talking about cases where the compiler is able to compile the code, its not rejecting it yet, and hopefully isn't generating code with semantics counter to the user expectation. So there's a trade-off the developer must evaluate, in terms of whether to do the work to silence the warning, or just ignore it.
I suspect that if the diagnostic is able to provide feedback about how soon the Rust compiler will start rejecting the code, that will help project managers decide whether to invest resources in making a PR and/or fork.
If we de-duplicate the diagnostics so that you only see one per (crate, future-incompat-lint-id), then I think agree with this.
(I still think the ideal UX would provide a report at the end that further reduces the information, so that you get at most one line per crate; or perhaps even just one line with all the crates. But reaching that goal, or progress towards it, need not stop us from doing the aforementioned de-duplication.)
I agree with your description. However, I don't think instant gratification needs to be a goal here. Waiting a bit to see a single warning go away is not that onerous.
I think we should consider how often the various scenarios happen. From my experience with crater it often happens that a crate simply needs to bump its version because upstream has already fixed it. At least that's the case with older bugs.
Seems right.
And I think by being very subtle and not-at-all annoying, we promote inaction on the users part.
I like the general idea here, I think it is important. I am on the side of minimizing annoyance - I've found warnings from path deps to be pretty annoying and this sounds like it would be similar. I also think that what a downstream maintainer can do is pretty limited - assuming you've updated and filed an issue, there is now nothing you can do, but you keep seeing the warning (which might be about code you don't even use). In particular, I think one can't expect a downstream maintainer to work out if such a warning is significant or not (i.e., should they panic or ignore it) because we'd be doing this for soundness issues which are usually subtle and would need a lot of context to reason about.
compiler and language teams have been relatively conservative in changing existing future-incompatibility lints into hard errors.
I think this is a feature, not a bug.
My favoured solution would be for rustc to ignore cap-lints for future compat lints and always warn (modulo de-duping, I suppose). That seems like a minimal change and Cargo is not involved at all. Showing the warning once when the compiler or crate is updated seems like the right level of annoyance to me. I don't personally think there is a lot of benefit in adding the extra info about what to do about it - that will be obvious to most users, and for those who it isn't, they are just going to ignore it. I think any benefit is outweighed by having more lines of error message.