mirror of
https://github.com/rust-lang/cargo
synced 2024-10-13 19:22:33 +00:00
e5e68c4093
feat: `lints` feature ### What does this PR try to resolve? Implement rust-lang/rfcs#3389 which shifts a subset of `.cargo/config.toml` functionality to `Cargo.toml` by adding a `[lints]` table. This **should** cover all of the user-facing aspects of the RFC - This doesn't reduce what flags we fingerprint - This will fail if any lint name as `::` in it. What to do in this case was in the RFC discussion but I couldn't find the thread to see what all was involved in that discussion - This does not fail if a `[lints]` table is present or malformed unless nightly with the `lints` feature enabled - The idea is this will act like a `[lints]` table is present in an existing version of rust, ignore it - The intent is to not force an MSRV bump to use it. - When disabled, it will be a warning - When disabled, it will be stripped so we don't publish it Tracking issue for this is #12115. ### How should we test and review this PR? 1. Look at this commit by commit to see it gradually build up 2. Look through the final set of test cases to make sure everything in the RFC is covered I tried to write this in a way that will make it easy to strip out the special handling of this unstable feature, both in code and commit history ### Additional information I'd love to bypass the need for `cargo-features = ["lints"]` so users today can test it on their existing projects but hesitated for now. We can re-evaluate that later. I broke out the `warn_for_feature` as an experiment towards us systemitizing this stabilization approach which we also used with #9732. This works well when we can ignore the new information which isn't too often but sometimes happens. This does involve a subtle change to `profile.rustflags` precedence but its nightly and most likely people won't notice it? The benefit is its in a location more like the rest of the rustflags. |
||
|---|---|---|
| .. | ||
| build-std | ||
| testsuite | ||
| internal.rs | ||