std::ops::Try impl for std::task::Poll
I originally left out the `Try` impl for `Poll` because I was curious if we needed it, and @MajorBreakfast and I had discussed the potential for it to introduce confusion about exactly what control-flow was happening at different points. However, after porting a pretty significant chunk of Fuchsia over to futures 0.3, I discovered that I was *constantly* having to do repetitive matching on `Poll<Result<...>>` or `Poll<Option<Result<...>>>` in order to propagate errors correctly. `try_poll` (propagate `Poll::Ready(Err(..))`s) helped in some places, but it was far more common to need some form of conversion between `Result`, `Poll<Result<...>>`, and `Poll<Option<Result<...>>>`. The `Try` trait conveniently provides all of these conversions in addition to a more concise syntax (`?`), so I'd like to experiment with using these instead.
cc @seanmonstar
r? @aturon
Note: this change means that far more futures 0.1 code can work without significant changes since it papers over the fact that `Result` is no longer at the top-level when using `Stream` and `Future` (since it's now `Poll<Result<...>>` or `Poll<Option<Result<...>>>` instead of `Result<Poll<..>>` and `Result<Poll<Option<...>>>`).
ARM: expose `rclass` and `dsp` target features
- `dsp`: the subtarget supports the DSP (saturating arith. and such)
instructions
- `rclass`: target is a Cortex-R
Both features are useful to support ARM MCUs on `coresimd`.
Note: Cortex-R52 is the first Armv8-R with `neon` support.
r? @alexcrichton
cc @japaric
Impl Executor for Box<E: Executor>
removes the need for the compatibility lib between futures 0.1 and 0.3 to use a wrapper type to implement Executor for Box<Executor>
Format linker args in a way that works for gcc and ld
Pass multiple linker arguments rather than concatenate with commas (fixes#52634).
`-l library` -> `-llibrary` to work with apple's ld.
To build with apple's ld I'm currently also passing `-C link-args="-arch x86_64 -macosx_version_min 10.13.0"`. I'll try and understand the latter flag better before PRing that.
This PR currently works for me. Hopefully CI will pick up any grievous ramifications in other toolchains?
Thanks to @alexcrichton for the pointer to the relevant code!
Fix #[linkage] propagation though generic functions
Fixes#18804
In the non-local branch of `get_static` (where the fix was implemented) `span_fatal` had to be replaced with `bug!` as we have no span in that case.
Don't match on region kinds when reporting NLL errors
First half (by number of tests affected) of the changes to "does not live long enough".
Now that lexical MIR borrowck is gone, region kinds are always ReVar, so matching on them to change errors does nothing.
Changes "borrowed value only lives until here" to "`x` is dropped here while still borrowed".
r? @pnkfelix cc @nikomatsakis
Clarify what a task is
Currently we call two distinct concepts "task":
1. The top-level future that is polled until completion
2. The lightweight "thread" that is responsible for polling the top-level future. What additional data beside the future is stored in this type varies between different `Executor` implementations.
I'd prefer to return to the old formulation by @alexcrichton:
```rust
/// A handle to a "task", which represents a single lightweight "thread" of
/// execution driving a future to completion.
pub struct Task {
```
Source: [`task_impl/mod.rs` in futures-rs 0.1](1328fc9e8a/src/task_impl/mod.rs (L49-L50))
I think that this change will make it much easier to explain everything.
r? @aturon
@cramertj
- `dsp`: the subtarget supports the DSP (saturating arith. and such)
instructions
- `rclass`: target is a Cortex-R
Both features are useful to support ARM MCUs on `coresimd`.
Note: Cortex-R52 is the first Armv8-R with `neon` support
Prefer `Option::map`/etc over `match` wherever it improves clarity
This isn't intended to change behavior anywhere. A lot of times statements like `match x { None => None, Some(y) => [...] }` can be rewritten using `Option::map` or `Option::and_then` in a way that preserves or improves clarity, so that's what I've done here.
I think it's particularly valuable to keep things in `libcore` and `libstd` pretty/idiomatic since it's not uncommon to follow the `[src]` links when browsing the rust-lang.org docs for std/core. If there's any concern about pushing style-based changes though, I'll happily back out the non-std/core commits here.
impl PartialEq+Eq for BuildHasherDefault
`BuildHasherDefault`is only one way of implementing `BuildHasher`. Clearly, every `BuildHasherDefault` for the same type `H` is identical, since it just uses `Default<H>` to construct `H`. In general, this is not true for every `BuildHasher`, so I think it is helpful to implement `PartialEq` and `Eq`.
Add unaligned volatile intrinsics
Surprisingly enough, it turns out that unaligned volatile loads are actually useful for certain (very niche) types of lock-free code. I included unaligned volatile stores for completeness, but I currently do not know of any use cases for them.
These are only exposed as intrinsics for now. If they turn out to be useful in practice, we can work towards stabilizing them.
r? @alexcrichton
Refactor rustdoc
This is based on https://github.com/rust-lang/rust/pull/52194 and so shouldn't be merged until it gets merged.
Now that plugin functionality has been removed, let's kill PluginManager. Additionally, rustdoc now follows the standard cargo layout instead of dumping everything at the top level.
r? @rust-lang/rustdoc
rustdoc: set panic output before starting compiler thread pool
When the compiler was updated to run on a thread pool, rustdoc's processing of compiler/doctest stderr/stdout was moved into each compiler thread. However, this caused output of the test to be lost if the test failed at *runtime* instead of compile time. This change sets up the `set_panic` call and output bomb before starting the compiler thread pool, so that the `Drop` call that writes back to the test's stdout happens after the test runs, not just after it compiles.
Fixes https://github.com/rust-lang/rust/issues/51162
