rust 1.44.0 fails to build in miri v0.1.0 on NetBSD/i386 8.0

[he32]

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

   Compiling miri v0.1.0 (/usr/pkgsrc/lang/rust/work/rustc-1.44.0-src/src/tools/miri)
error[E0478]: lifetime bound not satisfied
   --> src/tools/miri/src/diagnostics.rs:182:18
    |
182 | impl<'mir, 'tcx> EvalContextExt<'mir, 'tcx> for crate::MiriEvalContext<'mir, 'tcx> {}
    |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
note: lifetime parameter instantiated with the lifetime `'tcx` as defined on the impl at 182:12
   --> src/tools/miri/src/diagnostics.rs:182:12
    |
182 | impl<'mir, 'tcx> EvalContextExt<'mir, 'tcx> for crate::MiriEvalContext<'mir, 'tcx> {}
    |            ^^^^
note: but lifetime parameter must outlive the lifetime `'mir` as defined on the impl at 182:6
   --> src/tools/miri/src/diagnostics.rs:182:6
    |
182 | impl<'mir, 'tcx> EvalContextExt<'mir, 'tcx> for crate::MiriEvalContext<'mir, 'tcx> {}
    |      ^^^^

and several more instances of a similar error, and

error[E0495]: cannot infer an appropriate lifetime for lifetime parameter `'tcx` due to conflicting requirements
   --> src/tools/miri/src/helpers.rs:267:35
    |
267 |         impl<'ecx, 'mir, 'tcx, F> ValueVisitor<'mir, 'tcx, Evaluator<'tcx>>
    |                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
note: first, the lifetime cannot outlive the lifetime `'tcx` as defined on the impl at 267:26...
   --> src/tools/miri/src/helpers.rs:267:26
    |
267 |         impl<'ecx, 'mir, 'tcx, F> ValueVisitor<'mir, 'tcx, Evaluator<'tcx>>
    |                          ^^^^
note: ...so that the types are compatible
   --> src/tools/miri/src/helpers.rs:267:35
    |
267 |         impl<'ecx, 'mir, 'tcx, F> ValueVisitor<'mir, 'tcx, Evaluator<'tcx>>
    |                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = note: expected  `rustc_mir::interpret::ValueVisitor<'mir, 'tcx, machine::Evaluator<'tcx>>`
               found  `rustc_mir::interpret::ValueVisitor<'_, '_, machine::Evaluator<'_>>`
note: but, the lifetime must be valid for the lifetime `'mir` as defined on the impl at 267:20...
   --> src/tools/miri/src/helpers.rs:267:20
    |
267 |         impl<'ecx, 'mir, 'tcx, F> ValueVisitor<'mir, 'tcx, Evaluator<'tcx>>
    |                    ^^^^
note: ...so that the types are compatible
   --> src/tools/miri/src/helpers.rs:272:22
    |
272 |             type V = MPlaceTy<'tcx, Tag>;
    |                      ^^^^^^^^^^^^^^^^^^^
    = note: expected  `rustc_mir::interpret::visitor::Value<'mir, 'tcx, machine::Evaluator<'tcx>>`
               found  `rustc_mir::interpret::visitor::Value<'_, '_, machine::Evaluator<'tcx>>`

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.

Meta

rustc --version --verbose:

rustc 1.43.1
binary: rustc
commit-hash: unknown
commit-date: unknown
host: i686-unknown-netbsd
release: 1.43.1
LLVM version: 9.0

[he32]

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.

[jperkin]

I see this on x86_64-sun-solaris too, using 1.43.1 as bootstrap.

[he32]

Actually... @jperkin 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.

[mati865]

@RalfJung should Miri even build for stable releases?

[RalfJung]

No, Miri is not expected to build on beta/stable. It's a nightly-only tool.

[RalfJung]

@he32 why are you even trying to build Miri? Distro packages for stable Rust should not do that.

[jperkin]

We aren't specifically building it, or at least not that we're aware of, it's just being automatically built as part of python x.py -v build.

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: https://github.com/NetBSD/pkgsrc/blob/trunk/lang/rust/Makefile, it has a bunch of bits you can ignore but the CONFIGURE_ARGS and do-build target seem reasonably standard to me, but perhaps there's some flag there that is causing it to be included.

[RalfJung]

Hm, usually this is controlled (I think) by the tools array in config.toml. But miri shouldn't be in there by default... maybe it is by accident?

[he32]

The tools array setting is commented out in my config.toml, and says:

# Installs chosen set of extended tools if `extended = true`. By default builds all.
# If chosen tool failed to build the installation fails. If `extended = false`, this
# option is ignored.
#tools = ["cargo", "rls", "clippy", "rustfmt", "analysis", "src"]

However, also in my case, extended = true, but I think that is required to build Cargo, ref.

# Enable a build of the extended Rust tool set which is not only the compiler
# but also tools such as Cargo. This will also produce "combined installers"
# which are used to install Rust and Cargo together. This is disabled by
# default. The `tools` option (immediately below) specifies which tools should
# be built if `extended = true`.
extended = true

And as @jperkin says, our builds are started with either python x.py -v build or python x.py -v dist, so we're not (as far as I know) explicitly trying to build Miri.

[RalfJung]

@Mark-Simulacrum do you know what the default is for the tools list in config.toml, i.e., which tools get build by default with extended = true? I tried reading the code but couldn't figure it out.^^

[mati865]

@RalfJung ah I remember now.
Before #71346 all tools were built (just not installed unless selected). After my PR we are still building all the tools unless user configures tools in config.toml.

[RalfJung]

@mati865 so if before and after we built all tools, then what changed?^^

[mati865]

@RalfJung 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:

rust/src/bootstrap/tool.rs

Line 612 in 963bf52

&& builder.config.tools.as_ref().map_or(true, |tools| {

[RalfJung]

@mati865 so how can the BSD folks build cargo (and clippy?) but not Miri? That Rust code doesn't tell me that I'm afraid...^^

[RalfJung]

But it seems almost as if that code makes all tools enabled per default?

[mati865]

@mati865 so how can the BSD folks build cargo (and clippy?) but not Miri?

By uncommenting this line:

tools = ["cargo", "rls", "clippy", "rustfmt", "analysis", "src"]

But it seems almost as if that code makes all tools enabled per default?

Yeah, all tools are build by default when extended = true is enabled. To fix the issue one would have to detect whether the tool should build and use that instead of true in line 612.

[he32]

No, Miri is not expected to build on beta/stable. It's a nightly-only tool.

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:

   Compiling chrono v0.4.6
   Compiling vergen v3.0.4
   Compiling miri v0.1.0 (/usr/pkgsrc/lang/rust/work/rustc-1.43.0-src/src/tools/
miri)
    Finished release [optimized] target(s) in 19m 22s
      < ToolBuild { compiler: Compiler { stage: 1, host: "aarch64-unknown-netbsd
" }, target: "aarch64-unknown-netbsd", tool: "miri", path: "src/tools/miri", mod
e: ToolRustc, is_optional_tool: true, source_type: Submodule, extra_features: []
 }
    < Miri { compiler: Compiler { stage: 1, host: "aarch64-unknown-netbsd" }, ta
rget: "aarch64-unknown-netbsd", extra_features: [] }
    > CargoMiri { compiler: Compiler { stage: 1, host: "aarch64-unknown-netbsd" 
}, target: "aarch64-unknown-netbsd", extra_features: [] }
      > ToolBuild { compiler: Compiler { stage: 1, host: "aarch64-unknown-netbsd
" }, target: "aarch64-unknown-netbsd", tool: "cargo-miri", path: "src/tools/miri
", mode: ToolRustc, is_optional_tool: true, source_type: Submodule, extra_featur
es: [] }

etc. etc.

[RalfJung]

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.

Besides, the above statement looks really strange to an outsider like me.

What is odd about the statement of a tool being nightly-only and experimental? Miri is not part of the official stable rustup distribution either. It would be really odd if distro's stable Rust contained things that Rust itself does not distribute, wouldn't it?

[he32]

Besides, the above statement looks really strange to an outsider like me.

What is odd about the statement of a tool being nightly-only and experimental?

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 tools array setting in config.toml 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 rust off the ground.

[RalfJung]

I would have expected its build to be disabled by default in a release.

So would I. I didn't know we build it by default. I submitted #73232 to fix that, but unfortunately this touches barely documented parts of x.py that I do not understand (like the DEFAULT associated const).