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.^^