Rustdoc should show which marker traits a type implements

[sfackler]

I don't think there's any way right now to find out if some type is e.g. Sync without trying to compile code that depends on it.

[huonw]

cc #13231

(this is one of the motivating reasons for opt-in built-in bounds.)

[tomjakubowski]

Will this simply fall out naturally from OIBIT?

[tomjakubowski]

Now that Copy is opt-in, the impl shows up! Huzzah!

[lilyball]

OIBITs didn't solve this. Well, it solved it for Copy, but the traits that have default impls (e.g. unsafe impl Sync for .. { }) still don't show up in rustdoc. A trait will show the negative impl if it has one, but not if it inherits its negative impl from a field.

[lilyball]

Nominating. I really think this needs to be fixed. Not having Sync/Send properly documented on types can be a real source of confusion. As this is a documentation issue, it could come after 1.0, but if we're expecting a bunch of people to start jumping into Rust as soon as 1.0 is released (which seems reasonable), then we should really try and have this done before then.

[tomjakubowski]

I think the easiest solution is to walk all the impls for the type and check whether !Sized or !Share are among them. If not, synthesize a positive impl for documentation purposes. 

—
Sent from Mailbox

On Sat, Apr 11, 2015 at 4:22 PM, Kevin Ballard notifications@github.com
wrote:

Nominating. I really think this needs to be fixed. Not having Sync/Send properly documented on types can be a real source of confusion. As this is a documentation issue, it could come after 1.0, but if we're expecting a bunch of people to start jumping into Rust as soon as 1.0 is released (which seems reasonable), then we should really try and have this done before then.

Reply to this email directly or view it on GitHub:
#17606 (comment)

[pnkfelix]

Not 1.0; P-low. (Also, not clear how to solve this, since most of the time the presence/absence of an impl is dependent on the particular type parameters you are instantiated with.)

[aturon]

Hm, I would prefer P-medium here; I think this is a very important piece of documentation to provide.

[gnzlbg]

https://www.reddit.com/r/rust/comments/46e32h/structs_not_fully_described_w_r_t_send_sync_drop/

[kscz]

As an additional urge to boost the priority on this: as someone who has been learning Rust, this is still super bewildering for Copy. i32 and i64 both implement Copy (as far as I can tell), but https://doc.rust-lang.org/nightly/std/primitive.i32.html and https://doc.rust-lang.org/std/marker/trait.Copy.html don't list the integer types as being copy-able.

This is mostly confusing when I'm trying to explain to other people the difference between a type which implements move semantics and a type which implements copy semantics; some of the core types don't expose their underlying behavior in the documentation.

[aturon]

So it looks like Copy is working OK except for primitive types, which suggests there's just a bug in the handling there. (Whereas "auto traits" like Send are trickier)

@jonathandturner, if you wanted to do some rustdoc hacking, fixing the issue around Copy might be a reasonable place to dive in.

[nagisa]

Still an issue.

[frewsxcv]

Worth mention this issue: #33772

Not directly related, but remotely similar

[RalfJung]

My issue has been closed as a dupe of this one, so let me add that implemented kinds are not the only missing bit of information: Other things that rustdoc should show include variance of lifetime/type parameters and whether type parameters appear only below a pointer indirection (the latter being relevant for recursive types).

[Aaron1011]

I'd like to work on this.

[gnzlbg]

I wasted a reasonable amount of time today because I thought some type wasn't Send + Sync because rustdoc did not show this to me :/

[QuietMisdreavus]

Thanks to #47833 this issue is now resolved! Starting in tomorrow's nightly docs, there will be a new "Auto Trait Implementations" section showing off under what conditions a type impls Send or Sync.

[alexreg]

Great work on this! I’ve been waiting for this feature for a while now. :-)