| Age | Commit message (Collapse) | Author | Lines |
|
Implement Sync for SyncSender
r? @alexcrichton
|
|
|
|
|
|
|
|
Decompose Adjustment into smaller steps and remove the method map.
The method map held method callee information for:
* actual method calls (`x.f(...)`)
* overloaded unary, binary, indexing and call operators
* *every overloaded deref adjustment* (many can exist for each expression)
That last one was a historical ~~accident~~ hack, and part of the motivation for this PR, along with:
* a desire to compose adjustments more freely
* containing the autoderef logic better to avoid mutation within an inference snapshot
* not creating `TyFnDef` types which are incompatible with the original one
* i.e. we used to take a`TyFnDef`'s `for<'a> &'a T -> &'a U` signature and instantiate `'a` using a region inference variable, *then* package the resulting `&'b T -> &'b U` signature in another `TyFnDef`, while keeping *the same* `DefId` and `Substs`
* to fix #3548 by explicitly writing autorefs for the RHS of comparison operators
Individual commits tell their own story, of "atomic" changes avoiding breaking semantics.
Future work based on this PR could include:
* removing the signature from `TyFnDef`, now that it's always "canonical"
* some questions of variance remain, as subtyping *still* treats the signature differently
* moving part of the typeck logic for methods, autoderef and coercion into `rustc::traits`
* allowing LUB coercions (joining multiple expressions) to "stack up" many adjustments
* transitive coercions (e.g. reify or unsize after multiple steps of autoderef)
r? @nikomatsakis
|
|
|
|
|
|
Correct some stability versions
These were found by running tidy on stable versions of rust and finding
features stabilised with the wrong version numbers.
|
|
These were found by running tidy on stable versions of rust and finding
features stabilised with the wrong version numbers.
|
|
|
|
|
|
|
|
documentation to channel() and sync_channel(); adding more links #29377
|
|
|
|
|
|
|
|
This change adds links to to `Receiver`, `Iter`, `TryIter`, `IntoIter`,
`Sender`, `SyncSender`, `SendError`, `RecvError`, `TryRecvError`,
`RecvTimeoutError`, `TrySendError`, `Sender::send`, `SyncSender::send`,
`SyncSender::try_send`, `Receiver::recv`, `Receiver::recv_timeout`,
`Receiver::iter`, and `Receiver::try_iter`.
Examples added to `Receiver`, `Sender`, `Receiver::iter`.
|
|
|
|
This was never established as a convention we should follow in the 'More
API Documentation Conventions' RFC:
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md
|
|
Implement `fmt::Debug` for all structures in libstd.
Part of https://github.com/rust-lang/rust/issues/31869.
Also turn on the `missing_debug_implementations` lint at the crate
level.
|
|
Replace invalid use of `&mut` with `UnsafeCell` in `std::sync::mpsc`
Closes #36934
r? @alexcrichton
|
|
Part of https://github.com/rust-lang/rust/issues/31869.
Also turn on the `missing_debug_implementations` lint at the crate
level.
|
|
Closes #36934
|
|
|
|
Closes #37915
This commit enhances documentation with several links and
fixes an error in the `sync_channel` documentation as well:
`send` doesn't panic when the senders are all disconnected
|
|
The `bound` argument in `std::sync::mpsc::sync:channel(bound: usize)` was not defined in the documentation.
|
|
|
|
[tracking issue](https://github.com/rust-lang/rust/issues/27749)
|
|
Closes #32114
|
|
|
|
|
|
|
|
Stabilized
* `Cell::as_ptr`
* `RefCell::as_ptr`
* `IpAddr::is_{unspecified,loopback,multicast}`
* `Ipv6Addr::octets`
* `LinkedList::contains`
* `VecDeque::contains`
* `ExitStatusExt::from_raw` - both on Unix and Windows
* `Receiver::recv_timeout`
* `RecvTimeoutError`
* `BinaryHeap::peek_mut`
* `PeekMut`
* `iter::Product`
* `iter::Sum`
* `OccupiedEntry::remove_entry`
* `VacantEntry::into_key`
Deprecated
* `Cell::as_unsafe_cell`
* `RefCell::as_unsafe_cell`
* `OccupiedEntry::remove_pair`
Closes #27708
cc #27709
Closes #32313
Closes #32630
Closes #32713
Closes #34029
Closes #34392
Closes #34285
Closes #34529
|
|
Add a method to the mpsc::Receiver for producing a non-blocking iterator
Currently, the `mpsc::Receiver` offers methods for receiving values in both blocking (`recv`) and non-blocking (`try_recv`) flavours. However only blocking iteration over values is supported. This PR adds a non-blocking iterator to complement the `try_recv` method, just as the blocking iterator complements the `recv` method.
Use-case
-------------
I predominantly use rust in my work on real-time systems and in particular real-time audio generation/processing. I use `mpsc::channel`s to communicate between threads in a purely non-blocking manner. I.e. I might send messages from the GUI thread to the audio thread to update the state of the dsp-graph, or from the audio thread to the GUI thread to display the RMS of each node. These are just a couple examples (I'm probably using 30+ channels across my various projects). I almost exclusively use the `mpsc::Receiver::try_recv` method to avoid blocking any of the real-time threads and causing unwanted glitching/stuttering. Now that I mention it, I can't think of a single time that I personally have used the `recv` method (though I can of course see why it would be useful, and perhaps the common case for many people).
As a result of this experience, I can't help but feel there is a large hole in the `Receiver` API.
| blocking | non-blocking |
|------------|--------------------|
| `recv` | `try_recv` |
| `iter` | 🙀 |
For the most part, I've been working around this using `while let Ok(v) = r.try_recv() { ... }`, however as nice as this is, it is clearly no match for the Iterator API.
As an example, in the majority of my channel use cases I only want to check for *n* number of messages before breaking from the loop so that I don't miss the audio IO callback or hog the GUI thread for too long when an unexpectedly large number of messages are sent. Currently, I have to write something like this:
```rust
let mut take = 100;
while let Ok(msg) = rx.try_recv() {
// Do stuff with msg
if take == 0 {
break;
}
take -= 1;
}
```
or wrap the `try_recv` call in a `Range<usize>`/`FilterMap` iterator combo.
On the other hand, this PR would allow for the following:
```rust
for msg in rx.try_iter().take(100) {
// Do stuff with msg
}
```
I imagine this might also be useful to game devs, embedded or anyone doing message passing across real-time threads.
|
|
instead of break from the loop
|
|
stability attributes
|
|
|
|
|
|
|
|
Currently, the `mpsc::Receiver` offers methods for receiving values in
both blocking (`recv`) and non-blocking (`try_recv`) flavours. However
only blocking iteration over values is supported. This commit adds a
non-blocking iterator to complement the `try_recv` method, just as the
blocking iterator complements the `recv` method.
|
|
|
|
|
|
These types were already `!Sync`, but this improves error messages when
they are used in contexts that require `Sync`, aligning them with
conventions used with `Rc`, among others.
|
|
|
|
These explicit lifetimes can be ommitted because of lifetime elision
rules. Instances were found using rust-clippy.
|
|
Minimal fix for https://github.com/rust-lang/rust/issues/30563
This covers all the public structs I think; except for Iter and
IntoIter, which I don't know if or how they should be handled.
|
|
|
|
Minimal fix for https://github.com/rust-lang/rust/issues/30563
This covers all the public structs I think; except for Iter and
IntoIter, which I don't know if or how they should be handled.
|
|
|
|
|