-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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: fix intra-link for generic trait impls #92792
Conversation
|| match (impl_type.kind(), ty.kind()) { | ||
(ty::Adt(def, _), ty::Adt(tydef, _)) => { | ||
debug!("adt def_id: {:?}", def.did); | ||
def.did == tydef.did | ||
} | ||
(ty::Foreign(def_id), ty::Foreign(tydef_id)) => def_id == tydef_id, | ||
_ => false, |
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.
@camelid your intuition was right: this piece was necessary, but I was not sure at the time how to compare them, but I think this is the way: if they both having matching types, we compare the def_id
alone, this allows users to write Foo
without the generic type parameters, and still have it match with Foo<T>
. That's my understanding.
Regarding the Foreign
, I'm not sure what that means to be honest, any ideas how can I test that case too to avoid regressions again?
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.
I think that explanation sounds right.
The Foreign
is an extern type
I believe (feature gate #![feature(extern_types)]
; issue #43467).
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.
@camelid I actually realised there are already tests for Foreign, and because the ty::Foreign
only has one field, the def_id
, doing a ==
covers what we are doing. The tests are passing without this case in the match
. I removed them.
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 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.
That test doesn't test trait impls on extern types, though. Can you please add a test case for that?
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.
It's true that TyKind
has derived Eq
, but Ty
manually implements it and uses pointer equality (because Ty
s are interned).
What I was asking is why it's okay to skip manually equating Foreign
but not Adt
.
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.
@camelid ah I see. I'm not sure then... I suppose we have the same question about all the other types, not just Foreign
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.
Oh 🤦
The reason it's necessary for Adt
s is because we want to ignore generics since the ty
we're matching against may just have placeholders (or similar). Can you add a comment about that?
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's what I meant with my initial comment on this piece #92792 (comment), I didn't get my message through well 😁
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.
Yeah, I think I read your message and understood partially but then got confused later 😆
38af78e
to
fb89bf0
Compare
a647025
to
4a94f5f
Compare
4a94f5f
to
efdf119
Compare
efdf119
to
5138606
Compare
5138606
to
ae20500
Compare
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.
Thanks!
@bors r+ |
📌 Commit ae20500 has been approved by |
@camelid thanks for your review! |
Beta-nominating because I believe the regression is on beta now. |
…cs, r=camelid rustdoc: fix intra-link for generic trait impls fixes rust-lang#92662 r? `@camelid`
…cs, r=camelid rustdoc: fix intra-link for generic trait impls fixes rust-lang#92662 r? ``@camelid``
…cs, r=camelid rustdoc: fix intra-link for generic trait impls fixes rust-lang#92662 r? ```@camelid```
…cs, r=camelid rustdoc: fix intra-link for generic trait impls fixes rust-lang#92662 r? ````@camelid````
…askrgr Rollup of 10 pull requests Successful merges: - rust-lang#92487 (Fix unclosed boxes in pretty printing of TraitAlias) - rust-lang#92581 (ARMv6K Horizon - Enable default libraries) - rust-lang#92619 (Add diagnostic items for macros) - rust-lang#92635 (rustdoc: Yet more intra-doc links cleanup) - rust-lang#92646 (feat: rustc_pass_by_value lint attribute) - rust-lang#92706 (Clarify explicitly that BTree{Map,Set} are ordered.) - rust-lang#92710 (Include Projections when elaborating TypeOutlives) - rust-lang#92746 (Parse `Ty?` as `Option<Ty>` and provide structured suggestion) - rust-lang#92792 (rustdoc: fix intra-link for generic trait impls) - rust-lang#92814 (remove unused FIXME) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
discussed in compiler triage meeting. backport approved. |
…r=Mark-Simulacrum [beta] Fix CVE-2022-21658 See https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html. Patches reviewed by `@m-ou-se.` Also backports: * resolve rustfmt issue with generated files rust-lang#92912 * rustdoc: fix intra-link for generic trait impls rust-lang#92792 * Fix rust logo style rust-lang#92764 r? `@ghost`
fixes #92662
r? @camelid