Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rustdoc should show which marker traits a type implements #17606

Closed
sfackler opened this issue Sep 28, 2014 · 18 comments
Closed

Rustdoc should show which marker traits a type implements #17606

sfackler opened this issue Sep 28, 2014 · 18 comments

Comments

@sfackler
Copy link
Member

@sfackler sfackler commented Sep 28, 2014

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
Copy link
Member

@huonw huonw commented Sep 28, 2014

cc #13231

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

@tomjakubowski
Copy link
Contributor

@tomjakubowski tomjakubowski commented Oct 9, 2014

Will this simply fall out naturally from OIBIT?

@tomjakubowski
Copy link
Contributor

@tomjakubowski tomjakubowski commented Dec 12, 2014

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

@lilyball
Copy link
Contributor

@lilyball lilyball commented Apr 11, 2015

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
Copy link
Contributor

@lilyball lilyball commented Apr 11, 2015

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
Copy link
Contributor

@tomjakubowski tomjakubowski commented Apr 12, 2015

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
Copy link
Member

@pnkfelix pnkfelix commented Apr 16, 2015

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
Copy link
Member

@aturon aturon commented Apr 23, 2015

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

@kscz
Copy link

@kscz kscz commented Mar 28, 2016

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
Copy link
Member

@aturon aturon commented Mar 28, 2016

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
Copy link
Member

@nagisa nagisa commented Jul 27, 2016

Still an issue.

@frewsxcv
Copy link
Member

@frewsxcv frewsxcv commented Sep 13, 2016

Worth mention this issue: #33772

Not directly related, but remotely similar

jonhoo added a commit to jonhoo/left-right that referenced this issue Apr 6, 2017
Note that !Sync doesn't yet show up in docs because of
rust-lang/rust#17606.
@RalfJung
Copy link
Member

@RalfJung RalfJung commented Apr 26, 2017

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).

@steveklabnik steveklabnik changed the title Rustdoc should show which kinds a type implements Rustdoc should show which marker traits a type implements Jun 6, 2017
@Aaron1011
Copy link
Member

@Aaron1011 Aaron1011 commented Oct 4, 2017

I'd like to work on this.

@gnzlbg
Copy link
Contributor

@gnzlbg gnzlbg commented Jan 31, 2018

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
Copy link
Member

@QuietMisdreavus QuietMisdreavus commented Feb 22, 2018

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
Copy link
Contributor

@alexreg alexreg commented Feb 22, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet