Interpret: AllocRange Debug impl, and use it more consistently

[RalfJung]

The two commits are pretty independent but it did not seem worth having two PRs for them.
r? @oli-obk

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

[RalfJung]

@oli-obk I know you said you didn't like these alloc_range(...) calls. OTOH, I tried changing all these functions to offset-size pairs, and it has the usual problems of a function where two arguments have the same type -- call sites become rather ambiguous-looking:

                alloc.write_scalar(Size::ZERO, a_size, a_val)?;

This is not an access of size zero.

By using alloc_range, at least one has to only learn once what that function does. I originally intended to use this as AllocRange { start: Size::ZERO, size: a_size }, which is very clear but also very verbose. I wish we could write _ { start: Size::ZERO, size: a_size } and have rustc infer the type... ;)

I am open to other ideas.

[oli-obk]

I recently saw a suggestion for start..+len, while neat, I find it an extension to the language that definitely does not carry its weight. The additional sigils aren't very obvious or googleable.

for slices we at least have x[start..][..len]. If indexing could return non-references we could go this route. We could use a method, which is likely not worse than what we have:

        let align = vtable
            .read_integer(alloc_range(
                pointer_size * u64::try_from(COMMON_VTABLE_ENTRIES_ALIGN).unwrap(),
                pointer_size,
            ))?
            .check_init()?;

could become

        let align = vtable
            .offset(pointer_size * u64::try_from(COMMON_VTABLE_ENTRIES_ALIGN).unwrap())
            .with_len(pointer_size)
            .read_integer()?
            .check_init()?;

[oli-obk]

fwiw, I think my main complaint is that read_scalar and friends take an AllocRange argument instead of first calling a method to offset/shrink the alloc and then just having no positional arguments to read_scalar

[RalfJung]

I recently saw a suggestion for start..+len, while neat, I find it an extension to the language that definitely does not carry its weight. The additional sigils aren't very obvious or googleable.

We could have a macro, alloc_range!(start..+len)? Though not sure if the parser will allow tat.

fwiw, I think my main complaint is that read_scalar and friends take an AllocRange argument instead of first calling a method to offset/shrink the alloc and then just having no positional arguments to read_scalar

Oh, interesting idea; I had not considered that. But what argument would the restrict-range function take? Another AllocRange? Or does offset change the start without changing the end (i.e., it changes both start and size, the way things are currently represented)?

[oli-obk]

Or does offset change the start without changing the end (i.e., it changes both start and size, the way things are currently represented)?

yea, this. Could probably use a better name

[oli-obk]

@bors r+

[bors]

📌 Commit 0832d1d has been approved by oli-obk