Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Recursively document methods via
Deref
traits #80653Recursively document methods via
Deref
traits #80653Changes from all commits
61c8aae
fd0ad03
06ce97c
8eaf68f
ea94607
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The impls were already documented by
render_deref_methods
and we don't want to duplicate them, is that the idea? The condition for runningrender_deref
is different from what you check here though: this checksDerefFor
and render_derf checksderef_impl.is_some()
. Is there any time those could be different? If not, could you add an assert?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two concepts at play here simultaneously which is a bit confusing, so I'll try to explain and then we can work out whatever comments or assertions might be helpful.
Let's consider a two level
Deref
case:The goal of
if let Some(impl_) = deref_impl
when callingrender_deref_methods
is to descend to the methods of theDeref
target: e.g. fromFoo
toBar
and fromBar
toBaz
.The goal of
if let AssocItemRender::DerefFor { .. } = what
is to restrict what we render when we have already descended at least one level: e.g. when we're atBar
andBaz
, we only want to show their methods and nothing else.Does that help at all? 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that helps me understand why these are different, thanks :) I still have my original question, although maybe I didn't word it very well. This
return
ignores synthetic impls, which is correct (theTarget
could implement Sized but not the original, and vice-versa), but it also ignores blanket and concrete impls. Where are those handled? Is it inrender_deref_items
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment, this change is preserving the previous behaviour: trait, synthetic, and blanket impls are all skipped for
Deref
targets (e.g.Bar
andBaz
in the above example). The methods in theDeref
target that we want to include are rendered by the top bit ofrender_assoc_items
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, thanks - I missed that this is only skipping trait impls, not inherent impls. I'm not sure that behavior is correct, but it doesn't need to be fixed here.