Default to --cap-lints=warn#12
Conversation
|
Sounds good! Unfortunately Also this seems worth documenting somewhere, it might cause some unexpected interactions. |
| // roots. If we do not cap lints, we can get lint failures outside core or std. | ||
| // We cannot set --cap-lints=allow because Cargo needs to parse warnings to understand the | ||
| // output of --print=file-names for crate-types that the target does not support. | ||
| if !self.rustflags.iter().any(|flag| flag.as_encoded_bytes().starts_with(b"--cap-lints")) { |
There was a problem hiding this comment.
You could use to_string_lossy with a FIXME suggesting to move to as_encoded_bytes once we drop support for older nightlies.
Why are we supporting older nightlies? |
|
Fair question. In xargo times I always made sure we supported older nightlies as well since not everyone always tracks the very latest nightly, and I carried that over to this library. Maybe supporting one year old nightlies is a bit too much, though I would like to support a few months worth of nightlies. |
2 participants
It took me a long time to figure out why we need to or should do this. Thanks @Nemo157 and @Nilstrieb for telling me to keep looking.
What confused me is that the
backtracecrate is actually turned into a module insidestd, and the sysroot depends onstdvia path dependency, so we have no lint capping by default when we buildbacktrace.I think lint capping is a prudent thing to do here to make things smoother in the future, even though I'm also going to try to fix the sources of warnings that come out of
cargo miri setup.