make --release enable--cap-lints warn

[JanZerebecki]

Describe the problem you are trying to solve

It is common for operating systems package to be created using:

cargo build --release --locked
cargo install --no-track --root=/ --path .

Drift in default lints might cause this to fail, e.g. because rustc was updated. Where it would not fail with --cap-lints warn.

Everyone packaging rust could add RUSTFLAGS="--cap-lints warn" to the above, but it might be generally useful.

Describe the solution you'd like

Make --release enable --cap-lints warn similar to what is used for dependencies.

While there is a trade off between missing a problem that can be newly detected and causing new failures that weren't there before. It reads as a choice is already made. See #5998 .

It seems #3453 was supposed to make cargo install already behave that way. Though my test shows this doesn't work any more and install without any flags will fail after a build was made to succeed with --cap-lints warn. (Any reason this was changed? Is this worth a separate issue?)

Notes

[ehuss]

I don't think we would want to make this the default for the --release flag, as it can be very noisy (warnings are unfortunately quite common), and there is usually little the user can do to fix them.

You can view all warnings with the -vv flag. Unfortunately that also shows other output like build scripts, but it is an option that exists now.

Otherwise, I think adding the ability to explicitly control the cap-lints behavior is tracked in #4152.

[JanZerebecki]

That is or more accurately cap-lints forbid is the current default. Allow would be ok for me, though not preferred as it would hide warnings that are currently shown. I don't mean to raise the default cap-lints from allow to warn, but to lower it from forbid to warn (or allow if that is preferred).

Though I only tested with cargo version 1.42.1. If it changed recently, I'd need to retest. The changelog doesn't say anything, so I assume not.

This is not about lints triggered in dependencies but in the current / local project.

[alexcrichton]

Hm I think @JanZerebecki is asking for the opposite @ehuss? It sounds like you think this issue is about turning lints on in release mode, whereas this issue seems to rather be about preventing them from failing the build.

That being said I would not personally want to do this based on optimization, aand would prefer to defer to #4152 instead for a mechanism to configure the lint level.

[ehuss]

Yea, sorry, I misunderstood.

[ehuss]

Closing as a duplicate of #4152. There's definitely some value in having better control of lint capping, but how exactly that would be expressed isn't clear. We probably don't want to change the behavior of existing commands, so it would need to be some kind of option.