| Age | Commit message (Collapse) | Author | Lines |
|
|
|
We have to compare unknown_bottom as well, it is semantically relevant!
|
|
|
|
implement `libc::sched_setaffinity` on linux
fixes https://github.com/rust-lang/miri/issues/2749
the implementation, like `libc::sched_getaffinity`, just always returns `EINVAL`, which kind of simulates a device with zero cpus. I believe the idea is that callers of this function always do it to optimize, so they are likely to gracefully recover from this function returning an error.
based on the libc crate, these functions are also available on android and freebsd (but not on macos or windows). So should the implementation of the `sched_*` functions just be copied to the android and freebsd shims?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use the native unwind function in miri where possible
Continuation of https://github.com/rust-lang/miri/pull/3319
cc `@RalfJung`
|
|
|
|
|
|
Miri function identity hack: account for possible inlining
Having a non-lifetime generic is not the only reason a function can be duplicated. Another possibility is that the function may be eligible for cross-crate inlining. So also take into account the inlining attribute in this Miri hack for function pointer identity.
That said, `cross_crate_inlinable` will still sometimes return true even for `inline(never)` functions:
- when they are `DefKind::Ctor(..) | DefKind::Closure` -- I assume those cannot be `InlineAttr::Never` anyway?
- when `cross_crate_inline_threshold == InliningThreshold::Always`
so maybe this is still not quite the right criterion to use for function pointer identity.
|
|
Run tests for all specified targets
Currently cargo-miri uses the first target specified in the command line. However, when multiple targets are specified in a `cargo build` invocation, cargo will build for all of them.
Miri should match this behaviour to reduce surprises.
Fixes: #3460
|
|
|
|
This is an attempt to remove the magic from a lot of the numbers tested,
which should make things easier when it is time to add `f16` and `f128`.
A nice side effect is that these tests now cover all int <-> float
conversions with the same amount of tests.
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
Currently cargo-miri uses the first target specified in the command
line. However, when multiple targets are specified in a `cargo build`
invocation, cargo will build for all of them.
Miri should match this behaviour to reduce surprises.
Fixes: #3460
|
|
r=RalfJung
TB: Refine protector end semantics
Tree Borrows has protector end tag semantics, namely that protectors ending cause a [special implicit read](https://perso.crans.org/vanille/treebor/diff.0.html) on all locations protected by that protector that have actually been accessed. See also #3067.
While this is enough for ensuring protectors allow adding/reordering reads, it does not prove that one can reorder writes. For this, we need to make this stronger, by making this implicit read be a write in cases when there was a write to the location protected by that protector, i.e. if the permission is `Active`.
There is a test that shows why this behavior is necessary, see `tests/fail/tree_borrows/protector-write-lazy.rs`.
|
|
|
|
|
|
circumstances
|
|
|
|
|
|
Re-implement a type-size based limit
r? lcnr
This PR reintroduces the type length limit added in #37789, which was accidentally made practically useless by the caching changes to `Ty::walk` in #72412, which caused the `walk` function to no longer walk over identical elements.
Hitting this length limit is not fatal unless we are in codegen -- so it shouldn't affect passes like the mir inliner which creates potentially very large types (which we observed, for example, when the new trait solver compiles `itertools` in `--release` mode).
This also increases the type length limit from `1048576 == 2 ** 20` to `2 ** 24`, which covers all of the code that can be reached with craterbot-check. Individual crates can increase the length limit further if desired.
Perf regression is mild and I think we should accept it -- reinstating this limit is important for the new trait solver and to make sure we don't accidentally hit more type-size related regressions in the future.
Fixes #125460
|
|
Implement the `_mm256_zeroupper` and `_mm256_zeroall` intrinsics
These two intrinsics were missing from the original implementation of the AVX intrinsics.
Fortunately their implementation is trivial.
|
|
|
|
|
|
|
|
Add syscall `dup()` for unix target
Add support for `dup()` and `dup2()`.
Fixes #3454
|
|
|
|
Use the symbol_name query instead of trying to infer from the link_name attribute
This prevents the calculated name from going out of sync with exported_symbols. It also avoids having to special case the panic_impl lang item.
It also makes it easier to fix miri with https://github.com/rust-lang/rust/pull/127173.
|
|
|
|
|
|
attribute
This prevents the calculated name from going out of sync with
exported_symbols. It also avoids having to special case the panic_impl
lang item.
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 5c4ede88c61e746ed5c852d7a7e38ab1a824ae52, reversing
changes made to 95332b89187bb6a0c910574cfeff1933b619565a.
|
|
readme: tweak wording around soundness
Miri *can* tell you whether your code is sound when it finds UB -- it's not sound in that case. It can give negative answers, just not positive ones.
|
|
|
|
Automatic Rustup
|
|
|
|
r=RalfJung
Fix miri.bat to not exit unconditionally
#3703 has a small typo causing it to regress ./miri.bat to not working at all.
This PR fixes it. Tested on Windows 11, with stable toolchain missing as well as installed.
```test
./miri toolchain
error: toolchain 'stable-x86_64-pc-windows-msvc' is not installed
Failed to build miri-script. Is the 'stable' toolchain installed?
```
Closes #3714
|
|
|
|
|
|
unnecessary std frame restriction
|