-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Cleanup: Use rustc's same_type
for our same_tys
#5528
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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