Should `miri` be built by default with `--enable-extended` for realease tarballs?

[dilyanpalauzov]

config.toml.sample contains

#tools = [
#    … #    "miri", "cargo-miri" # for dev/nightly channels
#]

This means that when building from a realease tarball with ./configure --enable-optimize-llvm --enable-extended --llvm-root=/usr/local --enable-profiler --enable-llvm-link-shared --enable-sanitizers --enable-local-rust --disable-docs --target=x86_64-unknown-linux-gnu --enable-vendor using https://static.rust-lang.org/dist/rustc-1.86.0-src.tar.xz miri will not be compiled or installed.

This was discussed in #129171 and the hyperlinks versioned there.

I do not understand, should miri and cargo-miri be built by default, from the realease tarball, or be built only by default for dev/nightly channels?

$ miri --version
rustc 1.86.0-nightly (05f9846f8 2025-03-31) (built from a source tarball)

$ cargo miri --version
miri 0.1.0

My understanding from #100134 is that miri should not be built by default when release tarball is used, but it is built by default.

[onur-ozkan]

There is a logical conflict where tarball sources use the src/ci/channel value as the default channel if not set manually, but at the same time the "dist" profile (which is the default profile for tarball sources) sets the channel to "nightly".

#139574 attempts to resolve this.

[dilyanpalauzov]

Just for my understanding, as this very same thing has changed several times.

Should miri be built by default with --enable-extended for realease tarballs or not?

[onur-ozkan]

Answer is already in bootstrap.example.toml:

"miri", "cargo-miri" # for dev/nightly channels