doc(notable_trait) for impls by conradludgate · Pull Request #94904 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Allows the #[doc(notable_trait)] attribute to be used on impls as well as trait definitions.
(rust-highfive has picked a reviewer for you, use r? to override)
Relevant to the rustdoc team, which will review and decide on the PR/issue.
label
I'm currently running into this issue locally so I'm struggling to test it
Fixed by running ./x.py doc --stage 2
Comment on lines 2100 to 2264
| #[doc(notable_trait)] |
|---|
| impl Write for Formatter<'_> { |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, if we decide to land this, I wonder if we should rename notable_trait to just notable...
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would make sense, since it'll cover notable_trait and notable_impl into one
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it were to simply be called notable, I wonder if there would be usefulness in extending it to other areas too... notable fields? Is that useful? I don't know, but maybe it's worth exploring...
Perhaps notable items in e.g. a module would be useful. I have a module defining many structs and enums (100+) that doesn't make sense to split up, I wonder if notability is relevant to that or not.
@conradludgate if you can resolve the conflicts we can get this merged
ping from triage:
@conradludgate - looks like this is ready for review
FYI: when a PR is ready for review, send a message containing@rustbot ready to switch to S-waiting-on-review so the PR is in the reviewer's backlog, else it sits idle.
@rustbot ready
Status: Awaiting review from the assignee but also interested parties.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Closing in favor of #94909, since that says it is a successor to this PR.
Closing in favor of #94909, since that says it is a successor to this PR.
Sorry, That's not what I meant by successor - I meant this PR is a dependency
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Hey! It looks like you've submitted a new PR for the library teams!
If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.
Examples of T-libs-api changes:
- Stabilizing library features
- Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
- Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
- Changing public documentation in ways that create new stability guarantees
- Changing observable runtime behavior of library APIs
Status: Awaiting review from the assignee but also interested parties.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
This comment has been minimized.
This change is insta-stable, so needs a completed FCP to proceed.
label
Are you implying that this is waiting for the author to implement the change to just notable? Or do you mean that a decision there still needs to be reached?
I think it'd be better to have the team saying it's ok for the renaming, then the code update and finally the FCP.
Status: Awaiting decision from the relevant subteam (see the T- label).
label
Some changes occurred in src/librustdoc/clean/types.rs
cc @camelid
Some changes occurred in src/tools/rust-analyzer
cc @rust-lang/rust-analyzer
Some changes occurred in HTML/CSS/JS.
cc @GuillaumeGomez, @jsha
I have rebased to resolve conflicts. I tentatively renamed the attribute but haven't touched the feature name.
The RA changes don't look particularly problematic (this time), but we prefer having them merged through the RA upstream when possible (i.e. when they're not necessary to keep the code building or running). That file is generated automatically, and this can make synchronizing the subtree really annoying.
I wasn't sure about the RA stuff. I mostly did a find-replace and then cleaned up all the changes. I'll remove those changes from the commit then, thanks for letting me know
This comment has been minimized.
I don't have a strong opinion on renaming it, but I am in favor of allowing individual impls to be marked as notable.
@GuillaumeGomez IIUC this is blocked on a naming decision by the rustdoc team and FCP.
Labels
This change is insta-stable, so needs a completed FCP to proceed.
Status: Awaiting decision from the relevant subteam (see the T- label).
Relevant to the rustdoc team, which will review and decide on the PR/issue.