| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
interpret: pass MemoryKind to adjust_alloc_base_pointer
Another puzzle piece for https://github.com/rust-lang/miri/pull/3475.
The 2nd commit renames base_pointer -> root_pointer; that's how Tree Borrows already calls them and I think the term is more clear than "base pointer". In particular, this distinguishes it from "base address", since a root pointer can point anywhere into an allocation, not just its base address.
https://github.com/rust-lang/rust/pull/124018 has been rolled up already so I couldn't add it there any more.
r? ```@oli-obk```
|
|
directly call handle_alloc_error
Also test more codepaths. There's like 5 different things that can happen on allocation failure! Between `-Zoom`, `#[alloc_error_handler]`, and `set_alloc_error_hook`, we have 3 layers of behavior overrides. It's all a bit messy.
https://github.com/rust-lang/rust/pull/112331 seems intended to clean this up, but has not yet reached consensus.
|
|
|
|
|
|
|
|
also in Miri, "base tag" -> "root tag"
|
|
|
|
|
|
Box::into_raw: make Miri understand that this is a box-to-raw cast
Turns out https://github.com/rust-lang/rust/pull/122647 went a bit too far in cleaning up `Box`... we still need a hack in `Box::into_raw`. The nicer fix would be to make Stacked Borrows not care about reference-to-raw-pointer casts, but it's unclear whether that will ever be possible without going to full Tree Borrows.
Fixes https://github.com/rust-lang/miri/issues/3473.
|
|
implement support for __rust_alloc_error_handler
Fixes https://github.com/rust-lang/miri/issues/3439
|
|
|
|
|
|
Explainer: https://zetanumbers.github.io/book/async-drop-design.html
https://github.com/rust-lang/rust/pull/121801
|
|
|
|
|
|
|
|
add some basic support for GetFullPathNameW
This is the last missing piece to make std `path::` tests work on Windows.
|
|
Handle Miri sysroot entirely outside the Miri driver
(Extracted from https://github.com/rust-lang/miri/pull/3409)
This entirely moves the responsibility of setting miri-sysroot to whatever *invokes* the Miri driver. cargo-miri knows whether it is inside rustdoc or not and can adjust accordingly. I previously avoided doing that because there are a bunch of places that are invoking the driver (cargo-miri, the ui test suite, `./miri run`, `./x.py run miri`) and they all need to be adjusted now. But it is also somewhat less fragile as we usually have more information there -- and we can just decide that `./miri run file.rs --sysroot path` is not supported. The advantage of this is that the driver is reasonably clean and doesn't need magic environment variables like MIRI_SYSROOT, and we don't have to fight rustc_driver to use a different default sysroot. Everything is done in cargo-miri (and the other much simpler driver wrappers) where it can hopefully be debugged much better.
|
|
|
|
fix error display for './miri run --dep'
Fixes https://github.com/rust-lang/miri/issues/3463
|
|
|
|
|
|
passed to the driver
|
|
|
|
|
|
Signed-off-by: findseat <penglili@outlook.com>
|
|
also `move`
|
|
coroutine-closures
|
|
|
|
|
|
Fix capture analysis for by-move closure bodies
The check we were doing to figure out if a coroutine was borrowing from its parent coroutine-closure was flat-out wrong -- a misunderstanding of mine of the way that `tcx.closure_captures` represents its captures.
Fixes #123251 (the miri/ui test I added should more than cover that issue)
r? `@oli-obk` -- I recognize that this PR may be underdocumented, so please ask me what I should explain further.
|
|
|
|
rename ptr::from_exposed_addr -> ptr::with_exposed_provenance
As discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/To.20expose.20or.20not.20to.20expose/near/427757066).
The old name, `from_exposed_addr`, makes little sense as it's not the address that is exposed, it's the provenance. (`ptr.expose_addr()` stays unchanged as we haven't found a better option yet. The intended interpretation is "expose the provenance and return the address".)
The new name nicely matches `ptr::without_provenance`.
|
|
|
|
|
|
|
|
to build the C lib
|
|
|
|
|
|
This is an alternative to #121920
|
|
Stabilize `unchecked_{add,sub,mul}`
Tracking issue: #85122
I think we might as well just stabilize these basic three. They're the ones that have `nuw`/`nsw` flags in LLVM.
Notably, this doesn't include the potentially-more-complex or -more-situational things like `unchecked_neg` or `unchecked_shr` that are under different feature flags.
To quote Ralf https://github.com/rust-lang/rust/issues/85122#issuecomment-1681669646,
> Are there any objections to stabilizing at least `unchecked_{add,sub,mul}`? For those there shouldn't be any surprises about what their safety requirements are.
*Semantially* these are [already available on stable, even in `const`, via](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=bdb1ff889b61950897f1e9f56d0c9a36) `checked_*`+`unreachable_unchecked`. So IMHO we might as well just let people write them directly, rather than try to go through a `let Some(x) = x.checked_add(y) else { unsafe { hint::unreachable_unchecked() }};` dance.
I added additional text to each method to attempt to better describe the behaviour and encourage `wrapping_*` instead.
r? rust-lang/libs-api
|
|
|
|
|
|
|
|
Add libc direct test for shims and update CONTRIBUTING.md
Add more ``libc`` direct test for shims as mentioned in #3179.
Changes:
- Added ``libc`` direct tests for ``rename`` and ``ftruncate64``
- Added the command for running ``pass-dep`` test in ``CONTRIBUTING.md``
|
|
|
|
|
|
Miri subtree update
r? `@ghost`
|
