Oli Scherer

still working on this now and then, keeping it open is not useful

We could have a `.cargo/miri.toml` that we process ourselves

This project is almost ready (as in compiling and testing on Travis) again, I have a PR against rustc ready that should fix all the tests. After that we can...

Yea.... I don't think we should care too much about users doing horrible things. If you do care, don't enable the ffi feature ^^

well, at the very least we could support a file per unsupported target that lists all the passing tests that should keep passing (and make it easy to bless that...

should we just try the main message first and then the label, or should we explicitly opt into checking the label?

I think the only way forward for this would be to change `libsqlite3-sys` to use `#[cfg(miri)]` to do a pure-Rust in-memory implementation (beyond compiling the C library to Rust via...

I guess to resolve this issue properly we should add something to https://github.com/rust-lang/miri/blob/master/CONTRIBUTING.md that says what things are in scope of miri and what are out of scope

> I think I experimented with this a while ago, but I didn't find it to be particularly useful because I've noticed in the codebases I'm responsible for, there's virtually...

I took the liberty of formatting your json to make it easier to read. So I believe the issue is that the format changed and I should have updated `pandoc-ast`...