miri engine: Stacked Borrows NG
For more refined tracking in miri, we do return untagged pointers from the memory abstraction after allocations and let the caller decide how to tag these.
Also refactor the `tag_(de)reference` hooks so they can be more easily called in the ref-to-place and place-to-ref methods, and reorder things in validation: validation calls ref-to-place which (when running in miri) triggers some checks, so we want to run it rather late and catch other problems first. We also do not need to redundantly check the ref to be allocated any more, the checks miri does anyway imply thath.
r? @oli-obk
Unchecked thread spawning
# Summary
Add an unsafe interface for spawning lifetime-unrestricted threads for
library authors to build less-contrived, less-hacky safe abstractions
on.
# Motivation
So a few years back scoped threads were entirely removed from the Rust
stdlib, the reason being that it was possible to leak the scoped thread's
join guards without resorting to unsafe code, which meant the concept
was not completely safe, either.
Only a maximally-restrictive safe API for thread spawning was kept in the
stdlib, that requires `'static` lifetime bounds on both the thread closure
and its return type.
A number of 3rd party libraries sprung up to offer their implementations
for safe scoped threads implementations.
These work by essentially hiding the join guards from the user, thus
forcing them to join at the end of an (internal) function scope.
However, since these libraries have to use the maximally restrictive
thread spawning API, they have to resort to some very contrived manipulations
and subversions of Rust's type system to basically achieve what this commit does
with some minimal restructuring of the current code and exposing a new unsafe
function signature for spawning threads without lifetime restrictions.
Obviously this is unsafe, but its main use would be to allow library authors
to write safe abstractions with and around it.
To further illustrate my point, here's a quick summary of the hoops that,
for instance `crossbeam`, has to jump through to spawn a lifetime unrestricted
thread, all of which would not be necessary if an unsafe API existed as part
of the stdlib:
1. Allocate an `Arc<Option<T>>` on the heap where the result with type
`T: 'a` will go (in practice requires `Mutex` or `UnsafeCell` as well).
2. Wrap the desired thread closure with lifetime bound `'a` into another
closure (also `..: 'a`) that returns `()`, executes the inner closure and
writes its result into the pre-allocated `Option<T>`.
3. Box the wrapping closure, cast it to a trait object (`FnBox`) and
(unsafely) transmute its lifetime bound from `'a` to `'static`.
So while this new `spawn_unchecked` function is certainly not very relevant
for general use, since scoped threads are so common I think it makes sense
to expose an interface for libraries implementing these to build on.
The changes implemented are also very minimal: The current `spawn` function
(which internally contains unsafe code) is moved into an unsafe `spawn_unchecked`
function, which the safe function then wraps around.
# Issues
- ~~so far, no documentation for the new function (yet)~~
- the name of the function might be controversial, as `*_unchecked` more commonly
indicates that some sort of runtime check is omitted (`unrestricted` may be
more fitting)
- if accepted, it might make sense to add a freestanding `thread::spawn_unchecked`
function similar to the current `thread::spawn` for convenience.
Fixes#54705
When constructing synthetic auto trait impls, we may come across
multiple predicates involving the same type, trait, and substitutions.
Since we can only display one of these, we pick the one with the 'most
strict' lifetime paramters. This ensures that the impl we render the
user is actually valid (that is, a struct matching that impl will
actually implement the auto trait in question).
This commit exapnds the definition of 'more strict' to take into account
inference variables. We always choose a predicate without inference
variables over a predicate with inference variables.
Delayed CTFE backtraces
This renames the env var that controls CTFE backtraces from `MIRI_BACKTRACE` to `RUST_CTFE_BACKTRACE` so that we can use `MIRI_BACKTRACE` in the miri tool to only show backtraces of the main miri execution.
It also makes `RUST_CTFE_BACKTRACE` only show backtraces that actually get rendered as errors, instead of showing them eagerly when the `Err` happens. The current behavior is near useless in miri because it shows about one gazillion backtraces for errors that we later catch and do not care about. However, @oli-obk likes the current behavior for rustc CTFE work so it is still available via `RUST_CTFE_BACKTRACE=immediate`.
NOTE: This is based on top of https://github.com/rust-lang/rust/pull/53821. Only [the last three commits](https://github.com/oli-obk/rust/compare/sanity_query...RalfJung:ctfe-backtrace) are new.
Fixes https://github.com/rust-lang/rust/issues/53355
Before parsing argument names and types, try to consume an incorrectly
included doc comment or attribute in order to recover and continue
parsing the rest of the fn definition.
PR #51953 enabled the Atomic*.{load,store} API on MSP430. Unfortunately, the
LLVM backend doesn't currently support those atomic operations, so this commit
removes the API and leaves instructions on how and when to enable it in the
future.
Rollup of 11 pull requests
Successful merges:
- #55148 (Implement FromStr for PathBuf)
- #55185 (path suggestions in Rust 2018 should point out the change in semantics)
- #55191 (Fix sub-variant doc display)
- #55199 (Impl items have generics)
- #55244 (Don't rerun MIR passes when inlining)
- #55252 (Add MaybeUninit::new)
- #55257 (Allow extern statics with an extern type)
- #55389 (Remove unnecessary mut in iterator.find_map documentation example, R…)
- #55406 (Update string.rs)
- #55412 (Fix an ICE in the min_const_fn analysis)
- #55421 (Add ManuallyDrop::take)
path suggestions in Rust 2018 should point out the change in semantics
Fixes#55130.
This commit extends existing path suggestions to link to documentation
on the changed semantics of `use` in Rust 2018.
Add ManuallyDrop::take
Tracking issue: #55422
Proposed in this form in https://internals.rust-lang.org/t/mini-rfc-manuallydrop-take/8679,
see that thread for some history.
A small convenience wrapper for `ManuallyDrop` that makes a pattern (taking ownership of the contained data in drop) more obvious.
Fix ordering of nested modules in non-mod.rs mods
Flatten relative offset into directory path before adding inline
(mod x { ... }) module names to the current directory path.
Fix#55094
The env var is now RUST_CTFE_BACKTRACE. Similar to RUST_BACKTRACE, it usually
only prints a backtrace when the error actually surfaces, not when it happens.
This makes a difference when we catch errors.
As per @oli-obk's request, one can set RUST_CTFE_BACKTRACE=immediate to get the
backtrace shown immediately.
Don't rerun MIR passes when inlining
Fixes#50411
r? @nikomatsakis
I updated your commit message with additional details. Let me know if any of that is incorrect. I also added the appropriate `compile-flags` directive to the test.
Thanks for you help on this!
cc @RalfJung related to your PR #55086
It would be nice to demonstrate the shining correctness here with more
run-rustfix tests than this, but unfortunately, that doesn't work with
multipart suggestions yet (#53934).
While we're here, reword the zero-use lifetime suggestion to "elide
the unused lifetime" instead of "remove it". (It's classier.)
Partial implementation of uniform paths 2.0 to land before beta
Reimplementation of uniform paths using in-scope resolution rather than canaries is a minor breaking change due to stricter future-proofing, so it needs to be landed before beta or backported later.
I hope to implement at least something until beta so we have less to backport.
r? @Mark-Simulacrum
