-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Cleanup: Use rustc's same_type
for our same_tys
#5528
Conversation
Ah, it might make sense to also check whether or not the FIXME was resolved already without this PR. Will do that tomorrow. |
bed9d9e
to
3cd7608
Compare
same_types
for our same_tys
same_type
for our same_tys
Hmm, generally |
A right, I'm going to give re-exporting a try later today 👍 |
☔ The latest upstream changes (presumably #5583) made this pull request unmergeable. Please resolve the merge conflicts. |
@phansch Did you have any success with reexporting? |
Not really. |
We can just keep it as it is right now, since the internal rustc lint doesn't trigger here. So I would be fine with this right now. (This again reminds me, that I wanted to revisit this internal rustc lint...) |
so rebase + CI pass = r=me |
@bors r=flip1995 |
📌 Commit 623faac has been approved by |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
This delegates our
same_tys
to ty::TyS::same_type toremove some duplication.
Our
same_tys
was introduced 4 years ago in #730. Before, it wasbuilding an inference context to be able to call
can_eq
to compare the types. Therustc-dev-guide
has some more detailsabout
can_eq
in Type Inference -> Trying equality.Now, using the rustc function, we are essentially comparing the
DefId
sof the given types, which also makes more sense, IMO.
I also confirmed that the FIXME is resolved via a bit of
dbg!
, howeverno UI tests seem to have been affected.
changelog: none