| Age | Commit message (Collapse) | Author | Lines |
|
Use `MPlaceTy` instead of `PlaceTy` in `FnArg` and ignore (copy) locals in an
earlier step ("Locals that don't have their address taken are as protected as
they can ever be").
This seems to be crucial for tail call support (as they can't refer to caller's
locals which are killed when replacing the stack frame).
|
|
Refactor pre-getopts command line argument handling
Rebased version of #111658. I've also fixed the Windows CI failure (although I don't have access to Windows to test it myself).
|
|
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #121863 (silence mismatched types errors for implied projections)
- #122043 (Apply `EarlyBinder` only to `TraitRef` in `ImplTraitHeader`)
- #122066 (Add proper cfgs for struct HirIdValidator used only with debug-assert)
- #122104 (Rust is a proper name: rust → Rust)
- #122110 (Make `x t miri` respect `MIRI_TEMP`)
- #122114 (Make not finding core a fatal error)
- #122115 (Cancel parsing ever made during recovery)
- #122123 (Don't require specifying unrelated assoc types when trait alias is in `dyn` type)
- #122126 (Fix `tidy --bless` on ̶X̶e̶n̶i̶x̶ Windows)
- #122129 (Set `RustcDocs` to only run on host)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
interpret: avoid a long-lived PlaceTy in stack frames
`PlaceTy` uses a representation that's not very stable under changes to the stack. I'd feel better if we didn't have one in the long-term machine state.
r? `@oli-obk`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Windows: Implement condvar, mutex and rwlock using futex
Well, the Windows equivalent: [`WaitOnAddress`,](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress) [`WakeByAddressSingle`](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-wakebyaddresssingle) and [`WakeByAddressAll`](https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-wakebyaddressall).
Note that Windows flavoured futexes can be different sizes (1, 2, 4 or 8 bytes). I took advantage of that in the `Mutex` implementation.
I also edited the Mutex implementation a bit more than necessary. I was having trouble keeping in my head what 0, 1 and 2 meant so I replaced them with consts.
I *think* we're maybe spinning a bit much. `WaitOnAddress` seems to be looping quite a bit too. But for now I've keep the implementations the same. I do wonder if it'd be worth reducing or removing our spinning on Windows.
This also adds a new shim to miri, because of course it does.
Fixes #121949
|
|
|
|
remove the ability to disable ABI checking
This got deprecated in https://github.com/rust-lang/miri/pull/3071, about half a year ago.
`@rust-lang/miri` I think it's fine to remove this now.
|
|
|
|
Well, the Windows equivalent: `WaitOnAddress`, `WakeByAddressSingle` and `WakeByAddressAll`.
|
|
|
|
Bumps [mio](https://github.com/tokio-rs/mio) from 0.8.10 to 0.8.11.
- [Release notes](https://github.com/tokio-rs/mio/releases)
- [Changelog](https://github.com/tokio-rs/mio/blob/master/CHANGELOG.md)
- [Commits](https://github.com/tokio-rs/mio/compare/v0.8.10...v0.8.11)
---
updated-dependencies:
- dependency-name: mio
dependency-type: indirect
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
give macOS even more time to sleep
|
|
|
|
reorder rustc crate imports a bit
|
|
Conjob → Cronjob
Same as https://github.com/rust-lang/miri-test-libstd/pull/44
|
|
|
|
|
|
|
|
|
|
disable diagnostic deduplication
`@oli-obk` is there a better way to do this? Ideally we'd only set this when interpretation starts but the value in the compiler session seems to be immutable. I assume people will do `cargo check` before `cargo miri` so hopefully this won't lead to too much confusion.
Fixes https://github.com/rust-lang/miri/issues/3350
|
|
remove some flags that haven't had an effect in a while
`@rust-lang/miri` any objections to this?
|
|
|
|
|
|
|
|
Miri subtree update
r? `@ghost`
|
|
Fix .\miri fmt on Windows
This allows .\miri fmt to work on Windows. Closes #3317.
To reiterate, the problem with using `miri fmt` on Windows is that the CLI arguments to rustfmt are too long. Currently over 65,000 characters are used in the call to rustfmt, [which is incompatible with Windows](https://devblogs.microsoft.com/oldnewthing/20031210-00/?p=41553) as it is limited to (2^15 - 1) for all arguments plus all env vars.
Two things are done do get around this limit:
1. Call out to cargo-fmt for the crates that exist.
2. Batch rustfmt calls by length
Another alternative would be to just use rustfmt for everything and don't use cargo-fmt for the crates.
I don't know how much you guys may care about `miri fmt` time to run. I don't know the diff as it did not work before on my computer.
[I have another branch that solves this, but in a less permanent way](RossSmyth/miri/tree/windows-fmt). That was my initial attempt, and I learned that even with cargo-fmt and relative paths, the rustfmt call still has 27k characters. This is closer to the limit than I expected, so it would not be a permanent solution. So I went back to absolute paths & batching.
|
|
|
|
|
|
|
|
|
|
Windows: support getting the thread name
Also organize the thread name tests a bit.
|
|
|
|
|
|
|
|
|
|
|
|
less verbose
|
|
|
|
|
|
|
|
|