Closed
Description
Part of #29329
http://doc.rust-lang.org/std/sync/
Here's what needs to be done to close out this issue:
- the module-level documentation is very small. It should explain what the module is for in more detail, with some examples.
std::sync::atomic
could use links to the types it references.std::sync::atomic::fence
has very... dry docs that aren't very helpful. And there's no examples.ATOMIC_*_INIT
(link is just to BOOL but all of them) could use examples.Atomic*
(link is to Bool but all of them) are mostly fine, but could use links to other types and some beefing up generally.Barrier
needs a bunch of types linked.BarrierWaitResult
should explain its relationship withBarrier
and link to it.Condvar
needs examples on its methods.Once
needs to link toONCE_INIT
.PoisonError
needs examples.RwLock
needs examples, links to types, and a comparison between it andMutex
.WaitTimeoutResult
should link to the method that creates it.TryLockError
needs to link to the function that creates it.ONCE_INIT
needs a link toOnce
and some examples.LockResult
needs links.TryLockResult
needs links.Weak
could do a much better job of explaining itself.std::sync::mspc
needs a lot of links. The docs are good but a bit jargon-heavy, expanding those would be nice.IntoIter
needs more links and to explain how you get one.Iter
is the same.Receiver
needs links, examples, and more explanation of what it is.RecvError
needs to link torecv
.SendError
needs links.Sender
has the same issues asReceiver
.SyncSender
has the same asSender
.TryIter
needs to link to how to create one.RecvTimeoutError
needs to link torecv_timeout
.TryRecvError
needs to link totry_recv
TrySendError
needs to link totry_send
.channel
has almost no docs and it's the focus of this module!sync_channel
should point tochannel
and then tell how it's different.
Metadata
Metadata
Assignees
Labels
Area: Documentation for any part of the project, including the compiler, standard library, and toolsCategory: An issue tracking the progress of sth. like the implementation of an RFCCall for participation: Help is requested to fix this issue.Call for participation: Medium difficulty. Experience needed to fix: Intermediate.Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.Medium priority
Activity
iuliuv commentedon Jan 11, 2016
Possible inconsistency in the Rust documentation about channels:
https://doc.rust-lang.org/std/sync/mpsc/fn.sync_channel.html
Function std::sync::mpsc::sync_channel
"As with asynchronous channels, all senders will panic in send if the Receiver has been destroyed"
https://doc.rust-lang.org/std/sync/mpsc/struct.SyncSender.html
Struct std::sync::mpsc::SyncSender:
fn send(&self, t: T) -> Result<(), SendError>
"This function will never panic, but it may return Err if the Receiver has disconnected and is no longer able to receive information."
kmcallister commentedon Sep 19, 2016
I'm working on updating the
Arc
docs to more closely match the refinedRc
docs from #36571.steveklabnik commentedon Mar 8, 2017
I am happy to mentor anyone who wants to tackle this issue.
projektir commentedon Mar 26, 2017
@steveklabnik for all the ones that need links, are you talking about for example the types wrapped in
<code>
tags, such asSender
under thestd::sync::mpsc::Receiver
page? Is it safe to say that as general rule every type under a<code>
tag should link to the page for that type? Is there other linking on these pages you would expect to see?steveklabnik commentedon Mar 27, 2017
Yes, exactly. Note that sometimes there is a bug here; that is, certain kinds of docs get rendered on two pages and so the links won't work. I don't think that's an issue here, but our tools will catch those cases, so you shouldn't worry about it too much, but figured it'd be worth a mention.
That's pretty much it, just the stuff that's in
<code>
already.projektir commentedon Mar 27, 2017
Someone looks to have fixed up
Barrier
on nightly, btw.56 remaining items