running miri on rustc's test suite (run-pass) about miri HOT 46 CLOSED

fun fact: over the last month miri has gotten faster by a factor of two. At least the rustc test suite is finished twice as fast (number of tests went up! not down). This might either be due to improvements in rustc or due to improvements in miri.

from miri.

cargo_test_output.txt

see in first post for frequently updating file

from miri.

I think I broke it in 8b8c743

fixed it, report and PR coming in around an hour.

from miri.

updated log

from miri.

updated log.

from miri.

@gnzlbg Yeah, I refer to that idea as #[cfg(const)]. I guess bring it up again once we have RFCs for the more advanced const features Miri will enable.

from miri.

I'm running this now with full std mir enabled. We seem to have some previously unknown issues. But at least "no mir" errors have gone down to 2.

from miri.

Is there any way to run miri on the tests (#[test]) embedded in e.g. libstd? Most of the functional tests are actually such embedded tests, not run-pass tests.

from miri.

I have implementations for atomic_load, atomic_store, and atomic_xadd_relaxed which don't really do anything atomic, but it shouldn't matter when we don't have actual parallelism. A few others like the relaxed/non-relaxed variants and volatile_{load,store} should be just as easy.

I'll submit them soon and see how the test results change.

from miri.

I implemented the missing non atomic* intrinsics. Rustc seriously needs more tests, every intrinsic should at least have a run-pass test...

from miri.

use of fn(usize) -> Foo as fn(usize) -> u32
use of fn(&isize) -> Option<&isize> as fn(&isize) -> &isize

These are used when working with ffi... Should we support these cases?
I mean, any &isize can be transmuted to Option<&isize> and will be perfectly fine. Afaik this is guaranteed.

from miri.

to pass more tests we need to implement panic and print, some minor bugs are left, but these make up most of our failed tests.

from miri.

@oli-obk Any chance you could gist the entire test output? Assuming it contains both names and messages, it would let people like me to idly rummage through some of the maybe-UB tests.

from miri.

https://github.com/rust-lang/rust/blob/master/src/test/run-pass/mir_raw_fat_ptr.rs#L129 compares pointers into different allocs ( same in raw_fat_ptr.rs and mir_raw_fat_ptr.rs)

from miri.

I believe we could impose an ordering between unrelated allocations, but it wouldn't really be based on anything (it would just have to be deterministic).

I've seen a C interpreter that essentially has an arbitrary deterministic ordering, if I recall correctly.

from miri.

@solson Not in CTFE mode, though, right?

from miri.

@eddyb No, even in CTFE mode, if we can guarantee determinism.

from miri.

That's gonna expose some internals and differ depending on the mir optimizations that are run before evaluation.

from miri.

@solson If that determinism depends on the order things were evaluated in, that's not deterministic enough. It should be impossible for constant evaluation to observe any past interactions.
So maybe it'd make sense for "stack memory"? Not worth risking it though.

from miri.

It doesn't really expose anything. It's fine if it differs, so long as it runs the same given the same inputs (sources, flags, etc).

from miri.

@eddyb Yeah, it wouldn't work if you re-use the same uncleared Memory for different runs in some manner.

from miri.

I agree it sounds too risky for CTFE now.

from miri.

so long as it runs the same given the same inputs

Nope, that's not enough, the "inputs" are the MIR to evaluate and its generic parameters, not the whole compilation. I've described how getting this wrong even one bit can impact coherence and thus soundness.
Presumably there'd be some global Memory to cache results but its state should not be observable.

from miri.

I updated the top post with a list of the missing MIRs and a list of all panics happening inside miri. I also attached an updated raw output file.

from miri.

@oli-obk Can you re-run and update the OP? I was having some odd problems running it, but I can investigate stuff based on your results for now.

from miri.

sure

from miri.

There are a number of "invalid enum discriminant value read" results in your log that I can't reproduce. When I run those tests, they succeed.

from miri.

our rustc versions and/or test suite may differ due to different checkouts. My checkout is from February 2nd. My rustc is rustc 1.16.0-nightly (24055d0f2 2017-01-31)

from miri.

rustc 1.17.0-nightly (ea7a6486a 2017-02-04) with the latest checkout here. Maybe your packed struct PR a few days ago fixed things?

from miri.

I'll investigate

from miri.

ok, so updating rustc and the checkout fixed these bugs, so it must be something rustc changed that fixed it and not us, because I used the same miri code base. Regenerating log...

from miri.

I investigated "mir_adt_construction.rs" which failed with "tried to access memory with alignment 1, but alignment 8 is required".

It reduces to:

#[repr(packed)]
#[derive(PartialEq, Debug)]
struct Pakd {
    a: u64,
    b: u32,
    c: u16,
    d: u8,
    e: ()
}

fn test2() -> Pakd {
    Pakd { a: 42, b: 42, c: 42, d: 42, e: () }
}

fn main() {
  assert_eq!(test2(), Pakd { a: 42, b: 42, c: 42, d: 42, e: () });
}

I figure that this is actually a problem with the test, not Miri. The derived PartialEq implementation will access the packed field inappropriately (through references). Once rustc makes taking references to unaligned packed fields unsafe, then the derive(PartialEq) itself will fail to compile due to unsafe code.

from miri.

We should figure out which of the "no MIR" errors are in fact assertions we are hitting.

from miri.

@oli-obk Good point, I forgot that those could be test failures.

from miri.

every NO MIR FOR ...panic... is a test failure.

     17 NO MIR FOR `std::panicking::rust_panic_with_hook`
      7 NO MIR FOR `std::rt::begin_panic_fmt`
      7 NO MIR FOR `std::panicking::panicking`

some of these are useless... like a test testing --test compileflag, which we simply ignore and try to run the main function, which simply panics.

rerunning after 1 > -1 is true again, since that fixes a few of those.

from miri.

Is there a plan for supporting inline assembly?

from miri.

@gnzlbg No.

from miri.

So there will never be a way to work around that?

from miri.

If rust code could detect that is being run at compile-time, and branch on it, it could provide a different implementation of some functionality without features that miri will probably never understand (like inline assembly, SIMD intrinsics, llvm intrinsics, etc).

from miri.

Cool! Something like #[cfg(const)] would be a really pragmatic hack!

from miri.

@oli-obk It'd be nice to split the "error" count in the OP into true errors and "unsupported", so things like lack of threading don't inflate the error count. I'd also prefer to have them in separate lists if possible.

from miri.

• #[cfg(const)] is syntactical whereas this needs to decide based on what executes it

from miri.

Good point, it wouldn't actually use cfg.

from miri.

@oli-obk If you look at your 2 "MIR not found" errors, I'm pretty sure the :::: is from extern {...}, so these are most likely FFI.

from miri.

hmm... I think I implemented this in cargo miri. But I'm not sure how to run that inside the rustc build system.

from miri.

Also see https://github.com/RalfJung/miri-test-libstd/issues/1

from miri.