Change:
// Note: tools need to be also added to `Builder::get_step_descriptions` in `build.rs` // to make `./x.py build <tool>` work. tool_extended!((self, builder), <del> Cargofmt, rustfmt, "src/tools/rustfmt", "cargo-fmt", {}; CargoClippy, clippy, "src/tools/clippy", "cargo-clippy", {}; Clippy, clippy, "src/tools/clippy", "clippy-driver", {}; Miri, miri, "src/tools/miri", "miri", {}; CargoMiri, miri, "src/tools/miri/cargo-miri", "cargo-miri", {}; Rls, rls, "src/tools/rls", "rls", { </del> <ins> Cargofmt, rustfmt, "src/tools/rustfmt", "cargo-fmt", stable=true, {}; CargoClippy, clippy, "src/tools/clippy", "cargo-clippy", stable=true, {}; Clippy, clippy, "src/tools/clippy", "clippy-driver", stable=true, {}; Miri, miri, "src/tools/miri", "miri", stable=false, {}; CargoMiri, miri, "src/tools/miri/cargo-miri", "cargo-miri", stable=false, {}; Rls, rls, "src/tools/rls", "rls", stable=true, { </ins> builder.ensure(Clippy { compiler: self.compiler, target: self.target,

Discussion:
I have already successfully built rust 1.44.0 on NetBSD/amd64 8.0. Next I'm tackling NetBSD/i386 8.0, but that is not going as expected, the build errors out after hours of apparent successful building with and several more instances of a similar error, and I'm confused. Why would the amd64 build succeed and the i386 build fail when building the same sources, with what appears to be a rust language issue?? I expected the build on NetBSD/i386 8.0 to succeed. Instead, this happened: (see above). The bootstrap compiler is rust 1.43.1. :
BTW, I have also now received reports that 1.44.0 also fails to build on NetBSD/amd64 versions 9.99.64 and 9.99.65 ("-current" development versions), so this isn't just an i386 issue, apparently.
I see this on too, using 1.43.1 as bootstrap.
Actually... informed me that this build error is in fact non-fatal for the build as a whole, and now that I do a double take, that appears indeed to be the case -- the build completed despite the errors in this apparently-optional module. Still, the principle of general tidyness would dictate that this should be dealt with one way or the other.
should Miri even build for stable releases?
No, Miri is not expected to build on beta/stable. It's a nightly-only tool.
why are you even trying to build Miri? Distro packages for stable Rust should not do that.
We aren't specifically building it, or at least not that we're aware of, it's just being automatically built as part of . At least I don't see anything in our build target or configure arguments that appear out of the ordinary. The pkgsrc Makefile for rust is here: , it has a bunch of bits you can ignore but the and target seem reasonably standard to me, but perhaps there's some flag there that is causing it to be included.
Hm, usually this is controlled (I think) by the array in . But miri shouldn't be in there by default... maybe it is by accident?

The array setting is commented out in my , and says: However, also in my case, , but I think that is required to build Cargo, ref. And as says, our builds are started with either or , so we're not (as far as I know) explicitly trying to build Miri.
do you know what the default is for the list in , i.e., which tools get build by default with ? I tried reading the code but couldn't figure it out.^^
ah I remember now. Before all tools were built (just not installed unless selected). After my PR we are still building all the tools unless user configures in .
so if before and after we built all tools, then what changed?^^
users can now workaround that by specifying the tools to build For anyone who wants to fix it that PR also shows where to start:
so how can the BSD folks build cargo (and clippy?) but not Miri? That Rust code doesn't tell me that I'm afraid...^^
But it seems almost as if that code makes all tools enabled per default?
By uncommenting this line: Yeah, all tools are build by default when is enabled. To fix the issue one would have to detect whether the tool should build and use that instead of in line 612.
I reviewed the build logs for earlier rust versions I had lying around, and it looks like Miri was successfully built as part of rust 1.43.1, 1.43.0, 1.41.0, 1.40.0, 1.39.0, 1.38.0, and 1.37.0, hence my surprise that it didn't successfully build in 1.44.0. Besides, the above statement looks really strange to an outsider like me. Where the 1.44.0 build failed, I have in the build log for 1.43.1: etc. etc.
Yeah, most of the time Miri builds, and thus happens to also build when the beta is branched. But this time it didn't and that's okay. Miri is explicitly exempt from CI on our beta/stable branch. What is odd about the statement of a tool being nightly-only and experimental? Miri is not part of the official stable distribution either.

It would be really odd if distro's stable Rust contained things that Rust itself does not distribute, wouldn't it?
I read it as "Miri is never expected to build in stable / releases, but (mostly?) builds fine in the current development version." which struck me as really strange. Now it just looks like a "bad time" was encountered between cutting the release and the ability to build "Miri" which is more understandable once I understood it's experimental and optional. However, I'm a proponent of "sane defaults". If "Miri" is not expected to be built as part of a release, I would have expected its build to be disabled by default in a release. The suggestion to un-comment the array setting in is "not a default, more knowledge you need to possess and work you have to do to do a normal release build". There's also the issue of whether that list of tools is actively maintained... I would rather rely on "sane defaults" than having to do even more tinkering -- there's certainly more than enough of that already to get off the ground.
So would I. I didn't know we build it by default. I submitted to fix that, but unfortunately this touches barely documented parts of that I do not understand (like the associated const).