| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
fixing part of `miri test alloc/hashmap`.
|
|
|
|
|
|
|
|
missing foreign function
|
|
|
|
|
|
|
|
and make them separate from 'shims'
|
|
preserve all UB that the native intrinsic would have
|
|
|
|
|
|
And suggest adding the `#[coroutine]` to the closure
|
|
|
|
Dellvmize some intrinsics (use `u32` instead of `Self` in some integer intrinsics)
This implements https://github.com/rust-lang/compiler-team/issues/693 minus what was implemented in #123226.
Note: I decided to _not_ change `shl`/... builder methods, as it just doesn't seem worth it.
r? ``@scottmcm``
|
|
Miri: detect wrong vtables in wide pointers
Fixes https://github.com/rust-lang/miri/issues/3497.
Needed to catch the UB that https://github.com/rust-lang/rust/pull/123572 will start exploiting.
r? `@oli-obk`
|
|
|
|
|
|
|
|
isolation
|
|
|
|
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"
|
|
|
|
implement support for __rust_alloc_error_handler
Fixes https://github.com/rust-lang/miri/issues/3439
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: findseat <penglili@outlook.com>
|
|
|
|
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`.
|
|
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
|
|
Miri subtree update
r? `@ghost`
|
|
Report retags as distinct from real memory accesses for data races
This changes the error reporting for data races such that reference invariants are no longer reported as real read and writes.
Before:
```
Data race detected between (1) non-atomic write on thread `unnamed-6` and (2) non-atomic read on thread `unnamed-5` at alloc1034971+0x10c. (2) just happened here
```
After:
```
Data race detected between (1) non-atomic write on thread `unnamed-8` and (2) shared reference invariant on thread `unnamed-6` at alloc1018329+0x190. (2) just happened here
```
Non-atomic read accesses from the *other* thread don't have this information tracked so those are called `some potential non-atomic read access` here.
|
|
|
|
Let codegen decide when to `mem::swap` with immediates
Making `libcore` decide this is silly; the backend has so much better information about when it's a good idea.
Thus this PR introduces a new `typed_swap` intrinsic with a fallback body, and replaces that fallback implementation when swapping immediates or scalar pairs.
r? oli-obk
Replaces #111744, and means we'll never need more libs PRs like #111803 or #107140
|
|
|
|
|
|
|
|
r=oli-obk,wesleywiser
Move generic `NonZero` `rustc_layout_scalar_valid_range_start` attribute to inner type.
Tracking issue: https://github.com/rust-lang/rust/issues/120257
r? `@dtolnay`
|
|
|
|
|
