Nemo157

> I believe an automated tool that detect binary blobs of executable types in the downloaded code is a better solution for this problem than a database of known instances...

> However, warnings during docs.rs's call to `cargo doc` so checking `--cfg` will likely not be a problem for this use case. I do hope to one day surface warnings...

Depending on the expected scale, we could maybe automate this through github actions, have a rebuild request issue type and a script that runs on issue creation and queues the...

Doing much more than #898 does is going to necessitate reading the `Cargo.toml` of each crate and/or asking crates.io about them (the only other thing I think we can verify...

Yeah, I was thinking recording as a histogram, we've been recording build durations that way for a while now which can give some idea of the sort of volatility from...

You can see we pass it along to cargo: , it must be ignoring it for some reason though, probably related to the weirdness of a `--target`-less build; I can...

This is much bigger than just the `package.metadata.docs.rs.rustdoc-args` being ignored, all the additional args we use like `--static-root-path` are ignored too :facepalm:. This must be a pretty recent cargo bug,...

Ah no, it's because `attr_alias` sets `rustc-args` which makes us use `-Zhost-config -Ztarget-applies-to-host`, which then makes `build.rustdocflags` not apply. This actually needs a soon-to-be-fully-implemented feature of per-target rustdocflags to properly...

The issue is almost certainly the `kas/winit`, `kas/wayland` "features". We do a separate `cargo fetch` then `cargo rustdoc --offline --features=...`, during the `fetch` cargo pulls down every dependency that might...

I don't know how we would do 1, that would need some support from cargo to allow something like `cargo fetch --features kas/winit,kas/wayland` to ask it to fetch those transitive...