@RalfJ I am impressed with how easy it easy to run miri on things these days. Bravo! And thanks for the suggestion.
error: Miri evaluation error: no item granting read access to tag <untagged> found in borrow stack --> /home/dwrensha/src/capnproto-rust/capnp/src/private/layout.rs:2863:18 | 2863 | ((*b) & (1u8 << (boffset % BITS_PER_BYTE as u32) as usize)) != 0 | ^^^^ Miri evaluation error: no item granting read access to tag <untagged> found in borrow stack
oof. I'm not sure what that means.
Oh no, an
untagged. Not sure how to debug these
b a raw pointer by any chance?
Often this error means that after you created
b , you wrote via the original reference that you got
it also often means that you used a raw pointer outside of its "range of validity"
like, maybe you did
&x as *const _ and then
offset that pointer -- which is illegal, only
x may be accessed by raw ptrs
if you want to access the entire thing, call
&x as *const _ illegal?
@David Renshaw the issue where we track that is https://github.com/rust-lang/unsafe-code-guidelines/issues/134. the wider context is https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md and the blog posts and papers it links.
basically, we want the compiler to optimize based on assumptions like "
&mut pointers are unique", and to that effect we have to be very careful what we actually allow to be done with raw pointers
note that the cast itself is perfectly legal, as is accessing the element you casted, but going outside that range is not allowed by the current model. there might be other models that do allow this, but likely at the cost of significant extra complexity (so, making it harder to understand the model) and/or at the cost of optimization potential.
when I saw choices like this while designing Stacked Borrows, I usually decided to opt for the more restrictive choice. it is much easier to relax such constraints later than to tighten them.
basically, I wanted to see how much I could get away with :P
I added this to the list in the issue... but the list is pretty incomplete, this is probably the stacked borrows issue that comes up most freuqently (alongside https://github.com/rust-lang/unsafe-code-guidelines/issues/133)
re: https://github.com/capnproto/capnproto-rust/commit/3ea257068e9f7b6f3968a4ddb4669ff54ad79175, I wonder if there is a way to reduce the number of iterations or so? to get at least a tiny bit of fuzzing done with miri?
but yeah, I've had to disable such tests in other repos as well :/
RalfJ I am impressed with how easy it easy to run miri on things these days. Bravo! And thanks for the suggestion.
(totally forgot to reply) thanks, that is encouraging :)
I was bracing myself for needing to get some kind of xargo setup going. It was amazing to be able to
rustup component add and have it just work.
yeah I hacked that auto-setup during RustFest Rome and later wondered why I hadn't done it earlier :D
it's still just as ugly under the hood as it used to be, but hidden better^^
The other immediate thing that miri is finding is that I create (but never deference) pointers that are exactly one element beyond the end of an allocation. I can understand why miri want me to not do that (and I'll fix my code), but just for perspective: this is following a c++ pattern of using "1 past end of container" as the end iterator
one past the end of the container pointers are ok: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9b6b532e5b20d76ed422f7a86580af07
@David Renshaw by "pointer", do you mean "reference"? because references in Rust are a bit like references in C++ in that they must be dereferencable. the one-past-the-end thing is invalid for both. it is valid for raw pointers though.
Indeed, my code constructs such invalid references! I didn't realize it because it immediately casts them to raw pointers.
@David Renshaw ah... you might be interested in https://github.com/rust-lang/rfcs/pull/2582