| Age | Commit message (Collapse) | Author | Lines |
|---|
|
remove repetitive words
|
|
|
|
fix oversight from new miri-script
|
|
|
|
|
|
Signed-off-by: cui fliter <imcusg@gmail.com>
|
|
Rewrite miri script in rust
This is a sketch of a rewrite of miri script in Rust. It does not include changes made in https://github.com/rust-lang/miri/pull/2908 yet. Environment variables are not properly propagated yet, which is something I plan to address.
This PR is mostly a heads-up about the ongoing effort and it's state.
It's definitely not the cleanest code I've seen in my life, but my first goal was feature/interface parity. I will iterate on it a bit before marking it as ready.
I wonder though how this should be integrated/tested. Are you aware of anyone using `./miri` in their scripts?
I guess we should keep existing `miri` script in place and let it run miri-script package directly?
CI should probably `cargo check` this package as well.
Fixes #2883
|
|
|
|
|
|
|
|
refactor tests/utils a bit, and move some FS functions there
|
|
|
|
|
|
|
|
|
|
update Miri
r? `@ghost`
|
|
TB: Redefine trigger condition for protectors
The Coq formalization revealed that as currently implemented, read accesses did not always commute.
Indeed starting from a lazily initialized `Active` protected tag, applying a foreign read then a child read produces `Frozen`, but child read then foreign read triggers UB (because the child read initializes _before_ the `Active -> Frozen`).
This reformulation of when protectors trigger fixes that issue:
- instead of `Active + foreign read -> Frozen` and `Active -> Frozen` when protected is UB
- we do `Active + foreign read -> if protected { Disabled } else { Frozen }`
There is already precedent for transitions being dependent on the presence of a protector (`Reserved + foreign read -> if protected { Frozen } else { Reserved }`), and this has the nice side-effect of simplifying the protector trigger condition to just an equality check against `Disabled` since now there is protector UB iff a protected tag becomes `Disabled`.
In order not to introduce an extra `if`, it was decided that `Disabled -> Disabled` would be UB when protected, which was not the case previously. This is merely a theoretical for now because a protected `Disabled` is unreachable in the first place.
The extra test is not directly related to this modification, but also checks things related to protectors and lazy initialization.
|
|
|
|
|
|
|
|
|
|
Rename and allow `cast_ref_to_mut` lint
This PR is a small subset of https://github.com/rust-lang/rust/pull/112431, that is the renaming of the lint (`cast_ref_to_mut` -> `invalid_reference_casting`).
BUT also temporarily change the default level of the lint from deny-by-default to allow-by-default until https://github.com/rust-lang/rust/pull/112431 is merged.
r? `@Nilstrieb`
|
|
|
|
Unite bless environment variables under `RUST_BLESS`
Currently, Clippy and Miri both use an environment variable to indicate that output should be blessed, but they use different variable names. In order to improve consistency, this patch applies the following changes:
- Rename the variable `MIRI_BLESS` (as used in the Miri subtree) to `RUST_BLESS`
- Rename the variable `BLESS` (as used in the Clippy subtree) to `RUST_BLESS`
- Move emitting `RUST_BLESS` into `prepare_cargo_test` so it is always available (I need this for a WIP PR)
---
I prefer something like `RUST_BLESS` to `BLESS` just for a lower chance of conflict (not super common but other tools [do use `BLESS`](https://grep.app/search?q=%22BLESS%22&case=true&words=true&filter[lang][0]=Text&filter[lang][1]=Rust&filter[lang][2]=Python&filter[lang][3]=C%2B%2B&filter[lang][4]=Markdown&filter[lang][5]=C&filter[lang][6]=JSON)), but I can change it to whatever is preferred.
Original discussion: https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/BLESS.20env.20var.3A.20rename.20to.20CLIPPY_BLESS
r? `@oli-obk`
cc `@flip1995`
|
|
|
|
|
|
|
|
Replace in-tree `rustc_apfloat` with the new version of the crate
Replace the in-tree version of `rustc_apfloat` with the new version of the crate which has been correctly licensed. The new crate incorporates upstream changes from LLVM since the original port was done including many correctness fixes and has been extensively fuzz tested to validate correctness.
Fixes #100233
Fixes #102403
Fixes #113407
Fixes #113409
Fixes #55993
Fixes #93224
Closes #93225
Closes #109573
|
|
Currently, Clippy, Miri, Rustfmt, and rustc all use an environment variable to
indicate that output should be blessed, but they use different variable names.
In order to improve consistency, this patch applies the following changes:
- Emit `RUSTC_BLESS` within `prepare_cargo_test` so it is always
available
- Change usage of `MIRI_BLESS` in the Miri subtree to use `RUSTC_BLESS`
- Change usage of `BLESS` in the Clippy subtree to `RUSTC_BLESS`
- Change usage of `BLESS` in the Rustfmt subtree to `RUSTC_BLESS`
- Adjust the blessable test in `rustc_errors` to use this same
convention
- Update documentation where applicable
Any tools that uses `RUSTC_BLESS` should check that it is set to any value
other than `"0"`.
|
|
|
|
|
|
|
|
Automatic sync from rustc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
interpret: Unify projections for MPlaceTy, PlaceTy, OpTy
For ~forever, we didn't really have proper shared code for handling projections into those three types. This is mostly because `PlaceTy` projections require `&mut self`: they might have to `force_allocate` to be able to represent a project part-way into a local.
This PR finally fixes that, by enhancing `Place::Local` with an `offset` so that such an optimized place can point into a part of a place without having requiring an in-memory representation. If we later write to that place, we will still do `force_allocate` -- for now we don't have an optimized path in `write_immediate` that would avoid allocation for partial overwrites of immediately stored locals. But in `write_immediate` we have `&mut self` so at least this no longer pollutes all our type signatures.
(Ironically, I seem to distantly remember that many years ago, `Place::Local` *did* have an `offset`, and I removed it to simplify things. I guess I didn't realize why it was so useful... I am also not sure if this was actually used to achieve place projection on `&self` back then.)
The `offset` had type `Option<Size>`, where `None` represent "no projection was applied". This is needed because locals *can* be unsized (when they are arguments) but `Place::Local` cannot store metadata: if the offset is `None`, this refers to the entire local, so we can use the metadata of the local itself (which must be indirect); if a projection gets applied, since the local is indirect, it will turn into a `Place::Ptr`. (Note that even for indirect locals we can have `Place::Local`: when the local appears in MIR, we always start with `Place::Local`, and only check `frame.locals` later. We could eagerly normalize to `Place::Ptr` but I don't think that would actually simplify things much.)
Having done all that, we can finally properly abstract projections: we have a new `Projectable` trait that has the basic methods required for projecting, and then all projection methods are implemented for anything that implements that trait. We can even implement it for `ImmTy`! (Not that we need that, but it seems neat.) The visitor can be greatly simplified; it doesn't need its own trait any more but it can use the `Projectable` trait. We also don't need the separate `Mut` visitor any more; that was required only to reflect that projections on `PlaceTy` needed `&mut self`.
It is possible that there are some more `&mut self` that can now become `&self`... I guess we'll notice that over time.
r? `@oli-obk`
|
|
for visitors
|
|
|
|
|
|
|
|
|
|
|
