| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
These error messages include lines of the standard library which have
changed and so need updated.
|
|
|
|
|
|
diagnostics: do not repeat the entire message in the span label
|
|
|
|
|
|
|
|
also adjust the wording a little so that we don't say "the error occurred here" for two different spans
|
|
r=workingjubilee
UnsafePinned: also include the effects of UnsafeCell
This tackles https://github.com/rust-lang/rust/issues/137750 by including an `UnsafeCell` in `UnsafePinned`, thus imbuing it with all the usual properties of interior mutability (no `noalias` nor `dereferenceable` on shared refs, special treatment by Miri's aliasing model). The soundness issue is not fixed yet because coroutine lowering does not use `UnsafePinned`.
The RFC said that `UnsafePinned` would not permit mutability on shared references, but since then, https://github.com/rust-lang/rust/issues/137750 has demonstrated that this is not tenable. In the face of those examples, I propose that we do the "obvious" thing and permit shared mutable state inside `UnsafePinned`. This seems loosely consistent with the fact that we allow going from `Pin<&mut T>` to `&T` (where the former can be aliased with other pointers that perform mutation, and hence the same goes for the latter) -- but the `as_ref` example shows that we in fact would need to add this `UnsafeCell` even if we didn't have a safe conversion to `&T`, since for the compiler and Miri, `&T` and `Pin<&T>` are basically the same type.
To make this possible, I had to remove the `Copy` and `Clone` impls for `UnsafePinned`.
Tracking issue: https://github.com/rust-lang/rust/issues/125735
Cc ``@rust-lang/lang`` ``@rust-lang/opsem`` ``@Sky9x``
I don't think this needs FCP since the type is still unstable -- we'll finally decide whether we like this approach when `UnsafePinned` is moved towards stabilization (IOW, this PR is reversible). However, I'd still like to make sure that the lang team is okay with the direction I am proposing here.
|
|
Use the informative error as the main const eval error message
r? `@RalfJung`
I only did the minimal changes necessary to the const eval error machinery. I'd prefer not to mix test changes with refactorings 😆
|
|
|
|
|
|
|
|
TB: Track permissions on the byte-level
|
|
Co-authored-by: Ralf Jung <post@ralfj.de>
Co-authored-by: Johannes Hostert <jhostert@ethz.ch>
|
|
|
|
|
|
|
|
Add some track_caller info to precondition panics
Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful.
I thought of this while looking at https://github.com/rust-lang/rust/pull/129642#issuecomment-2311703898.
The changes to `tests/ui/const*` happen because the const-eval interpreter skips `#[track_caller]` frames in its backtraces.
The perf implications of this are:
* Increased debug binary sizes. The caller_location implementation requires that the additional data we want to display here be stored in const allocations, which are deduplicated but not across crates. There is no impact on optimized build sizes. The panic path and the caller location data get optimized out.
* The compile time hit to opt-incr-patched bitmaps happens because the patch changes the line number of some function calls with precondition checks, causing us to go from 0 dirty CGUs to 1 dirty CGU.
* The other compile time hits are marginal but real, and due to doing a handful of new queries. Adding more useful data isn't completely free.
|
|
interpret: do not force_allocate all return places
A while ago I cleaned up our `PlaceTy` a little, but as a side-effect of that, return places had to always be force-allocated. That turns out to cause quite a few extra allocations, and for a project we are doing where we marry Miri with a model checker, that means a lot of extra work -- local variables are just so much easier to reason about than allocations.
So, this PR brings back the ability to have the return place be just a local of the caller. To make this work cleanly I had to rework stack pop handling a bit, which also changes the output of Miri in some cases as the span for errors occurring during a particular phase of stack pop changed.
With these changes, a no-std binary with a function of functions that just take and return scalar types and that uses no pointers now does not move *any* local variables into memory. :)
r? `@oli-obk`
|
|
|
|
|
|
|
|
|
|
test direct usage of io::{stdout,stderr,stdin}
|
|
|
|
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #135808 (Implement Display for ``rustc_target::callconv::Conv``)
- #137432 (Add as_ascii_unchecked() methods to char, u8, and str)
- #139103 (deduplicate abort implementations)
- #140917 (checktools.sh: fix bashism)
- #141035 (turn lld warning on old gccs into info log)
- #141118 (Enable rust-analyzer to go from query definition to the corresponding provider field)
- #141121 (Only select true errors in `impossible_predicates`)
- #141125 (check coroutines with `TypingMode::Borrowck` to avoid cyclic reasoning)
- #141131 (Make some `match`es slightly more ergonomic in `librustdoc`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
deduplicate abort implementations
Currently, the code for process aborts is duplicated across `panic_abort` and `std`. This PR uses `#[rustc_std_internal_symbol]` to make the `std` implementation available to `panic_abort` via the linker, thereby deduplicating the code.
|
|
Implement Display for ``rustc_target::callconv::Conv``
Follow up of https://github.com/rust-lang/rust/pull/133103#discussion_r1885552854
|
|
|
|
|
|
Remove -Zunique-is-unique
|
|
|
|
|
|
interpret: better error message for out-of-bounds pointer arithmetic and accesses
Fixes https://github.com/rust-lang/rust/issues/93881
r? `@saethlin`
|
|
simd_select_bitmask: the 'padding' bits in the mask are just ignored
Fixes https://github.com/rust-lang/rust/issues/137942: we documented simd_select_bitmask to require the 'padding' bits in the mask (the mask can sometimes be longer than the vector; I am referring to these extra bits as 'padding' here) to be zero, mostly because nobody felt like doing the research for what should be done when they are non-zero. However, codegen is already perfectly happy just ignoring them, so in practice they can have any value. Some of the intrinsic wrappers in stdarch have trouble ensuring that they are zero. So let's just adjust the docs and Miri to permit non-zero 'padding' bits.
Cc ````@Amanieu```` ````@workingjubilee````
|
|
TB: add `Cell` state to support more fine-grained tracking of interior mutable data
|
|
|
|
accesses
|
|
|
|
Make thread scheduling fully random
|
|
|
