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

Show whether a trait is object-safe on its document page #85138

Closed
EFanZh opened this issue May 10, 2021 · 17 comments · Fixed by #113241
Closed

Show whether a trait is object-safe on its document page #85138

EFanZh opened this issue May 10, 2021 · 17 comments · Fixed by #113241
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@EFanZh
Copy link
Contributor

EFanZh commented May 10, 2021

So that it is easy for user to recognize object-safe traits.

@csmoe csmoe added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. labels May 10, 2021
@csmoe
Copy link
Member

csmoe commented May 10, 2021

pub fn is_object_safe(self, key: DefId) -> bool {

for the rustdoc side, just query the doc context with a given trait_def_id.

@vramana
Copy link
Contributor

vramana commented May 10, 2021

@rustbot claim

@vramana
Copy link
Contributor

vramana commented May 10, 2021

@csmoe Can you tell what are the relevant parts of rustdoc that needs to be changed?

@csmoe
Copy link
Member

csmoe commented May 12, 2021

@vramana sorry for late rely :)

let is_auto = cx.tcx.trait_is_auto(did);
clean::Trait {
unsafety: cx.tcx.trait_def(did).unsafety,
generics,
items: trait_items,
bounds: supertrait_bounds,
is_auto,
}

Add a is_object_safe field to clean::Trait, its value can be queried with cx.tcx.is_object_safe(did) like is_auto.

Then you can append the object-safety info into the render part here

fn item_trait(w: &mut Buffer, cx: &Context<'_>, it: &clean::Item, t: &clean::Trait) {

I know little about the render code, @jyn514 could you leave some notes about that?

@jyn514
Copy link
Member

jyn514 commented May 12, 2021

No, please do not add more fields to Trait. Query is_object_safe at the place it is used.

I don't know much about render, @GuillaumeGomez may have suggestions.

@GuillaumeGomez
Copy link
Member

I'm actually not sure what they want the end result to look like, so I don't know where to tell them to update the code. ;)

@tsoutsman
Copy link
Contributor

tsoutsman commented Aug 8, 2021

I'm actually not sure what they want the end result to look like, so I don't know where to tell them to update the code. ;)

@GuillaumeGomez maybe it could be a cube icon to the right of the new copy item import to clipboard button? On hover, there would be a tooltip saying Item is object-safe or Item is not object-safe. I'm not sure where you get icons for rustdoc, but heroicons have a cube and cube-transparent icon that could be used for object-safe, and object-unsafe traits respectively. The stroke-width could be reduced to fit in with the rest of the icons in rustdoc.

If @vramana doesn't want to work on it I'd be happy to give it a go.

@jsha
Copy link
Contributor

jsha commented Nov 18, 2021

Following up from the PR with some UI discussion.

I'd prefer not to add more icons up at the top of the page; we're already a bit crowded with icons. And there's no icon that has a broadly understood meaning of "object safe".

I like the approach in #89553, to write out "This trait is object-safe." But that PR puts it all the way at the top of the page, which is very high priority - and I would say object safety is more medium priority, so it should be lower on the page. One possibility would be to make an <h2> subheading in the top-doc docblock, but that results in using a lot of space for this. Our h2's are big!

What about this: Under "Implementors", we could have at the very top "This trait is object safe. References to types that implement this trait can be automatically coerced to dyn Foo". My reasoning here is that conceptually, dyn Foo is somewhat like an implementor of the trait.

@jyn514
Copy link
Member

jyn514 commented Nov 18, 2021

My reasoning here is that conceptually, dyn Foo is somewhat like an implementor of the trait.

I don't think this is necessarily true, you can have a dyn Foo that doesn't implement Foo. But putting the text under "implementors" seems as good a place as any 👍

@EFanZh
Copy link
Contributor Author

EFanZh commented Nov 28, 2021

@jyn514 Just out of curiosity, how can I have a dyn Foo that doesn’t implement Foo?

@jyn514
Copy link
Member

jyn514 commented Nov 28, 2021

@EFanZh I don't think that's actually true, I misremembered.

@jsha
Copy link
Contributor

jsha commented Dec 19, 2021

We have one 👍🏻 on:

Under "Implementors", we could have at the very top "This trait is object safe. References to types that implement this trait can be automatically coerced to dyn Foo".

Would anyone else like to weigh in? Good enough to proceed with implementation?

@GuillaumeGomez
Copy link
Member

Any update on this? :)

@camelid
Copy link
Member

camelid commented Feb 12, 2022

I'm not sure if it's already been suggested, but what about only showing a note if the trait is not object-safe?

@vramana vramana removed their assignment Mar 25, 2022
@jsha
Copy link
Contributor

jsha commented May 1, 2022

I like @camelid's suggestion to only show when a trait is not object safe, since that's the more unusual condition. If we do that, it doesn't fit logically under "Implementors" anymore. If we proceed with only marking non-object-safe traits, here are a couple of ideas:

  • Add a section after the top-doc, but before "Implementors", called "Object Safety", and put the text there.
  • Add information to the documentation of any method that causes the trait to be not object-safe.

@GoldsteinE
Copy link
Contributor

I think it’s still fine to mention under “Implementors” like “This trait is not object safe: dyn Trait doesn’t implement Trait”, but I also like the idea of the new section.

I see this issue doesn’t have an assignee currently, can I claim this?

@GuillaumeGomez
Copy link
Member

You can but since we didn't reach a consensus, any PR would hang around until we reach one.

@bors bors closed this as completed in 51b275b Nov 1, 2023
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Nov 1, 2023
Rollup merge of rust-lang#113241 - poliorcetics:85138-doc-object-safety, r=GuillaumeGomez

rustdoc: Document lack of object safety on affected traits

Closes rust-lang#85138

I saw the issue didn't have any recent activity, if there is another MR for it I missed it.

I want the issue to move forward so here is my proposition.

It takes some space just before the "Implementors" section and only if the trait is **not** object
safe since it is the only case where special care must be taken in some cases and this has the
benefit of avoiding generation of HTML in (I hope) the common case.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
9 participants