Rewrite how the HRTB algorithm matches impls against obligations. Instead of impls providing higher-ranked trait-references, impls now once again only have early-bound regions. The skolemization checks are thus moved out into trait matching itself. This allows to implement "perfect forwarding" impls like those described in #19730. This PR builds on a previous PR that was already reviewed by @pnkfelix.
r? @pnkfelix
Fixes#19730
This fixes#19978. The bug was introduced by 570325d, where if the type
of an Fn has not been inferred (strs[0] is "_") we slice from 1 to
0. We now explicitly check if `strs[0]` is a single element tuple.
lifetimes. This currently causes an ICE; it should (ideally) work, but
failing that at least give a structured error. For the purposes of
this PR, though, workaround is fine.
read (`//!` is intrusive) and annoying to edit (must maintain a prefix
on every line). Since the only purpose of a `doc.rs` file is to have a
bunch of text, using `/*!` and `*/` without indentations seems
appropriate.
This PR substantially narrows the notion of a "runtime" in Rust, and allows calling into Rust code directly without any setup or teardown.
After this PR, the basic "runtime support" in Rust will consist of:
* Unwinding and backtrace support
* Stack guards
Other support, such as helper threads for timers or the notion of a "current thread" are initialized automatically upon first use.
When using Rust in an embedded context, it should now be possible to call a Rust function directly as a C function with absolutely no setup, though in that case panics will cause the process to abort. In this regard, the C/Rust interface will look much like the C/C++ interface.
In more detail, this PR:
* Merges `librustrt` back into `std::rt`, undoing the facade. While doing so, it removes a substantial amount of redundant functionality (such as mutexes defined in the `rt` module). Code using `librustrt` can now call into `std::rt` to e.g. start executing Rust code with unwinding support.
* Allows all runtime data to be initialized lazily, including the "current thread", the "at_exit" infrastructure, and the "args" storage.
* Deprecates and largely removes `std::task` along with the widespread requirement that there be a "current task" for many APIs in `std`. The entire task infrastructure is replaced with `std::thread`, which provides a more standard API for manipulating and creating native OS threads. In particular, it's possible to join on a created thread, and to get a handle to the currently-running thread. In addition, threads are equipped with some basic blocking support in the form of `park`/`unpark` operations (following a tradition in some OSes as well as the JVM). See the `std::thread` documentation for more details.
* Channels are refactored to use a new internal blocking infrastructure that itself sits on top of `park`/`unpark`.
One important change here is that a Rust program ends when its main thread does, following most threading models. On the other hand, threads will often be created with an RAII-style join handle that will re-institute blocking semantics naturally (and with finer control).
This is very much a:
[breaking-change]
Closes#18000
r? @alexcrichton
The [final step](https://github.com/rust-lang/rust/pull/19654) of
runtime removal changes the threading/process model so that the process
shuts down when the main thread exits. But several shared resources,
like the helper thread for timeouts, are shut down when the main thread
exits (but before the process ends), and they are not prepared to be
used after shut down, but other threads may try to access them during
the shutdown sequence of the main thread.
As an interim solution, the `at_exit` cleanup routine is simply skipped.
Ultimately, these resources should be made to safely handle asynchronous
shutdown, usually by panicking if called from a detached thread when the
main thread is ending.
See issue for details https://github.com/rust-lang/rust/issues/20012
This is a [breaking-change] for anyone relying on `at_exit`.
