Add send_all for pipes #3020
Comments
ghost
assigned 
|
I'm not sure I follow what this would mean -- pipes are 1-1, so either this means sending on multiple pipes (which can be done with a vector iteration and doesn't need to be a primitive), or sending on a pipe whose other endpoint is a SharedChan. Conceivably this could mean iterating a |
|
If I recall correctly, |
|
ok, I'm gonna tag this and its friends as E-easy. |
The pipes compiler produced data types that encoded efficient and safe bounded message passing protocols between two endpoints. It was also capable of producing unbounded protocols. It was useful research but was arguably done before its proper time. I am removing it for the following reasons: * In practice we used it only for producing the `oneshot` protcol and the unbounded `stream` protocol and all communication in Rust use those. * The interface between the proto! macro and the standard library has a large surface area and was difficult to maintain through language and library changes. * It is now written in an old dialect of Rust and generates code which would likely be considered non-idiomatic. * Both the compiler and the runtime are difficult to understand, and likewise the relationship between the generated code and the library is hard to understand. Debugging is difficult. * The new scheduler implements `stream` and `oneshot` by hand in a way that will be significantly easier to maintain. This shouldn't be taken as an indication that 'channel protocols' for Rust are not worth pursuing again in the future. Concerned parties may include: @graydon, @pcwalton, @eholk, @bblum The most likely candidates for closing are #7666, #3018, #3020, #7021, #7667, #7303, #3658, #3295.
|
As #3018, not actually relevant to the protocol compiler |
|
Accepting P-low |
|
Should this be closed due to #7668? |
|
Is this still open because a |
|
The initial impetus for these issues has long since become outdated. The |
…stable, r=Veykril Don't suggest unstable items on stable toolchain Closes rust-lang#3020 This PR implements stability check in `ide-completion` so that unstable items are only suggested if you're on nightly toolchain. It's a bit unfortunate `CompletionContext::check_stability()` is spammed all over the crate, but we should call it before building `CompletionItem` as you cannot get attributes on the item it's completing from that struct. I looked up every callsite of `Builder::add_to()`, `Completions::add[_opt]()`, and`Completions::add_all()` and inserted the check wherever necessary. The tests are admittedly incomplete in that I didn't add tests for every kind of item as I thought that would be too big and not worthwhile. I copy-pasted some existing basic tests in every test module and adjusted them.
Automatic sync from rustc
This might also be called
broadcast.Part of #1255.
The text was updated successfully, but these errors were encountered: