When building this commit with ./x.py build --stage 0 src/librustc_mir, I get the following output:
error[E0432]: unresolved import `crate::interpret::InterpretCx`
--> src/librustc_mir/const_eval.rs:25:59
|
25 | InterpResult, InterpErrorInfo, InterpError, GlobalId, InterpretCx, StackPopCleanup,
| ^^^^^^^^^^^
| |
| no `InterpretCx` in `interpret`
| help: a similar name exists in the module: `InterpCx`
error[E0432]: unresolved import `crate::interpret::InterpretCx`
--> src/librustc_mir/transform/const_prop.rs:26:11
|
26 | self, InterpretCx, ScalarMaybeUndef, Immediate, OpTy,
| ^^^^^^^^^^^
| |
| no `InterpretCx` in `interpret`
| help: a similar name exists in the module: `InterpCx`
error[E0392]: parameter `'mir` is never used
--> src/librustc_mir/interpret/intern.rs:23:27
|
23 | struct InternVisitor<'rt, 'mir, 'tcx> {
| ^^^^ unused parameter
|
= help: consider removing `'mir` or using a marker such as `std::marker::PhantomData`
error: aborting due to 3 previous errors
The first two are expected, that's a mistake I made. The last one is wrong though, 'mir is used:
The thing is, it gets used as argument to CompileTimeEvalContext, which is defined in const_eval.rs, which had an import failure.
So it looks like the "unused lifetime" lint is a bit too aggressive here and considers a lifetime unused because the way it got used referred to a type that was in a failing module -- or so. I tried to minimize this but failed, here's my last attempt. But anyway I think this is a bug -- we want the user to look at the actual failure, not at spurious warnings that were caused by the failure.
When building this commit with
./x.py build --stage 0 src/librustc_mir
, I get the following output:The first two are expected, that's a mistake I made. The last one is wrong though,
'mir
is used:The thing is, it gets used as argument to
CompileTimeEvalContext
, which is defined inconst_eval.rs
, which had an import failure.So it looks like the "unused lifetime" lint is a bit too aggressive here and considers a lifetime unused because the way it got used referred to a type that was in a failing module -- or so. I tried to minimize this but failed, here's my last attempt. But anyway I think this is a bug -- we want the user to look at the actual failure, not at spurious warnings that were caused by the failure.