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: Provide information on Send/Sync/Sized, variance, pointer indirection, ... #41537

Closed
RalfJung opened this Issue Apr 25, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@RalfJung
Member

RalfJung commented Apr 25, 2017

There are some properties of types that are part of the "publicly visible interface" in the sense that they can be observed by other crates using these types, but they are not shown by rustdoc and usually can only be figured out by hunting through the implementation source code (potentially through many layers).

This is includes the information of when the type satisfies Send or Sync ("when" in the sense of "which bounds are needed on T to make Foo<T> be Send), when it is sized, what is the variance of lifetime and/or type parameters, and whether type parameters are occurring exclusively below a pointer indirection. (The latter is relevant to know whether struct Foo { f: T<Foo> } is legal.)

I recently hit this when I wanted to figure out when exactly MutexGuard, RwLockReadGuard and RwLockWriteGuard are Send or Sync -- I started chasing the source code, but actually it turns out to be much easier to "probe" these types by writing little programs that test whether the bounds are satisfied. Needless to say, that's not great. Ideally, rustdoc should present this information somewhere.

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Apr 25, 2017

Member

Possibly a duplicate of #33772?

Member

QuietMisdreavus commented Apr 25, 2017

Possibly a duplicate of #33772?

@ollie27

This comment has been minimized.

Show comment
Hide comment
@ollie27

ollie27 Apr 25, 2017

Contributor

I'd say this is a dupe of #17606.

Contributor

ollie27 commented Apr 25, 2017

I'd say this is a dupe of #17606.

@Mark-Simulacrum

This comment has been minimized.

Show comment
Hide comment
@Mark-Simulacrum

Mark-Simulacrum Apr 25, 2017

Member

Closing in favor of #17606. #33772 is similar (and perhaps a duplicate of #17606), but I think that #17606 is closer to what this specific issue is asking for.

Member

Mark-Simulacrum commented Apr 25, 2017

Closing in favor of #17606. #33772 is similar (and perhaps a duplicate of #17606), but I think that #17606 is closer to what this specific issue is asking for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment