| Age | Commit message (Collapse) | Author | Lines |
|
Rename `static_mut_ref` lint to `static_mut_refs`.
(cherry picked from commit 408eeae59d35cbcaab2cfb345d24373954e74fc5)
|
|
Miri subtree update
r? `@ghost`
|
|
freebsd add *stat calls interception support
|
|
|
|
Replacement of #114390: Add new intrinsic `is_var_statically_known` and optimize pow for powers of two
This adds a new intrinsic `is_val_statically_known` that lowers to [``@llvm.is.constant.*`](https://llvm.org/docs/LangRef.html#llvm-is-constant-intrinsic).` It also applies the intrinsic in the int_pow methods to recognize and optimize the idiom `2isize.pow(x)`. See #114390 for more discussion.
While I have extended the scope of the power of two optimization from #114390, I haven't added any new uses for the intrinsic. That can be done in later pull requests.
Note: When testing or using the library, be sure to use `--stage 1` or higher. Otherwise, the intrinsic will be a noop and the doctests will be skipped. If you are trying out edits, you may be interested in [`--keep-stage 0`](https://rustc-dev-guide.rust-lang.org/building/suggested.html#faster-builds-with---keep-stage).
Fixes #47234
Resolves #114390
`@Centri3`
|
|
Return a finite number of AllocIds per ConstAllocation in Miri
Before this, every evaluation of a const slice would produce a new AllocId. So in Miri, this program used to have unbounded memory use:
```rust
fn main() {
loop {
helper();
}
}
fn helper() {
"ouch";
}
```
Every trip around the loop creates a new AllocId which we need to keep track of a base address for. And the provenance GC can never clean up that AllocId -> u64 mapping, because the AllocId is for a const allocation which will never be deallocated.
So this PR moves the logic of producing an AllocId for a ConstAllocation to the Machine trait, and the implementation that Miri provides will only produce 16 AllocIds for each allocation. The cache is also keyed on the Instance that the const is evaluated in, so that equal consts evaluated in two functions will have disjoint base addresses.
r? RalfJung
|
|
This reverts commit 6d2b84b3ed7848fd91b8d6151d4451b3103ed816, reversing
changes made to 73bc12199ea8c7651ed98b069c0dd6b0bb5fabcf.
|
|
Stabilize `round_ties_even`
Closes #96710
`@rustbot` label -T-libs T-libs-api
|
|
|
|
Fix overflow check
Make MIRI choose the path randomly and rename the intrinsic
Add back test
Add miri test and make it operate on `ptr`
Define `llvm.is.constant` for primitives
Update MIRI comment and fix test in stage2
Add const eval test
Clarify that both branches must have the same side effects
guaranteed non guarantee
use immediate type instead
Co-Authored-By: Ralf Jung <post@ralfj.de>
|
|
Change return type of unstable `Waker::noop()` from `Waker` to `&Waker`.
The advantage of this is that it does not need to be assigned to a variable to be used in a `Context` creation, which is the most common thing to want to do with a noop waker. It also avoids unnecessarily executing the dynamically dispatched drop function when the noop waker is dropped.
If an owned noop waker is desired, it can be created by cloning, but the reverse is harder to do since it requires declaring a constant. Alternatively, both versions could be provided, like `futures::task::noop_waker()` and `futures::task::noop_waker_ref()`, but that seems to me to be API clutter for a very small benefit, whereas having the `&'static` reference available is a large reduction in boilerplate.
[Previous discussion on the tracking issue starting here](https://github.com/rust-lang/rust/issues/98286#issuecomment-1862159766)
|
|
Rollup of 10 pull requests
Successful merges:
- #118665 (Consolidate all associated items on the NonZero integer types into a single impl block per type)
- #118798 (Use AtomicU8 instead of AtomicUsize in backtrace.rs)
- #119062 (Deny braced macro invocations in let-else)
- #119138 (Docs: Use non-SeqCst in module example of atomics)
- #119907 (Update `fn()` trait implementation docs)
- #120083 (Warn when not having a profiler runtime means that coverage tests won't be run/blessed)
- #120107 (dead_code treats #[repr(transparent)] the same as #[repr(C)])
- #120110 (Update documentation for Vec::into_boxed_slice to be more clear about excess capacity)
- #120113 (Remove myself from review rotation)
- #120118 (Fix typo in documentation in base.rs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
`repr(transparent)` now silences the lint.
|
|
addres -> address
|
|
`Waker::noop()` now returns a `&'static Waker` reference, so it can be
passed directly to `Context` creation with no temporary lifetime issue.
|
|
|
|
Disallow reference to `static mut` and adding `static_mut_ref` lint
Closes #114447
r? `@scottmcm`
|
|
|
|
implement the rounding intrinsics using apfloat rounding
No reason to use host floats for these. Also merge two files that were both testing various float things.
|
|
|
|
|
|
|
|
|
|
|
|
Merge `unused_tuple_struct_fields` into `dead_code`
This implicitly upgrades the lint from `allow` to `warn` and places it into the `unused` lint group.
[Discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Moving.20.60unused_tuple_struct_fields.60.20from.20allow.20to.20warn)
|
|
Miri subtree update
r? `@ghost`
|
|
|
|
Otherwise the newly-detected dead code causes new output
|
|
Use `windows-sys` in windows tests
This PR adds `windows-sys` to `test_dependencies` so that we don't have to write out windows api bindings for each test.
|
|
|
|
|
|
NaN non-determinism for intrinsics and libm functions
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Jefffrey <22608443+Jefffrey@users.noreply.github.com>
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
do not allow ABI mismatches inside repr(C) types
In https://github.com/rust-lang/rust/pull/115476 we allowed ABI mismatches inside `repr(C)` types. This wasn't really discussed much; I added it because from how I understand calling conventions, this should actually be safe in practice. However I entirely forgot to actually allow this in Miri, and in the mean time I have learned that too much ABI compatibility can be a problem for CFI (it can reject fewer calls so that gives an attacker more room to play with).
So I propose we take back that part about ABI compatibility in `repr(C)`. It is anyway something that C and C++ do not allow, as far as I understand.
In the future we might want to introduce a class of ABI compatibilities where we say "this is a bug and it may lead to aborting the process, but it won't lead to arbitrary misbehavior -- worst case it'll just transmute the arguments from the caller type to the callee type". That would give CFI leeway to reject such calls without introducing the risk of arbitrary UB. (The UB can still happen if the transmute leads to bad results, of course, but it wouldn't be due to ABI weirdness.)
#115476 hasn't reached beta yet so if we land this before Dec 22nd we can just pretend this all never happened. ;) Otherwise we should do a beta backport (of the docs change at least).
Cc `@rust-lang/opsem` `@rust-lang/types`
|
|
Make mmap not use expose semantics
Fixes https://github.com/rust-lang/miri/issues/3041 per https://github.com/rust-lang/miri/issues/3041#issuecomment-1711235196
|
|
./miri run: default to edition 2021
Fixes https://github.com/rust-lang/miri/issues/2999
|
|
|
|
|
|
|
|
Add a regression test for rust#115145
Per https://github.com/rust-lang/rust/pull/118805#issuecomment-1855264860
|