On Tue, Aug 20, 2024 at 7:22 PM Matthew Maurer <mmaurer@xxxxxxxxxx> wrote: > > Sorry, I did miss that in the refresh. To respond to a few points > before I send up a replacement for this patch: No problem at all -- thanks! > I expect this to be potentially used for whether you're *allowed* to > set `RUST=y` - for example, if a particular sanitizer is enabled, you > may need to probe whether Rust+LLVM supports that sanitizer before > allowing RUST to be set to y. Yeah, makes sense if we do the dependency that way. > I don't think so - I can't think of a case where we'd want to error on > a warning from an empty crate (though that may be a failure of > imagination.) Do you have an example of a warning we might trip that > we'd want to make the build reject an option's availability? IIRC back then I was thinking about something like the "unknown target feature forwarded to backend" one, i.e. to identify whether a target feature was supported or not. However, that is not a warning even under `-Dwarning`s (https://github.com/rust-lang/rust/issues/91262) unless something recently changed. We can add it if/when we need it. Cheers, Miguel
