-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Cleanup: Use rustc's same_type for our same_tys
#5528
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
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_tyssame_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_tysto ty::TyS::same_type toremove some duplication.
Our
same_tyswas introduced 4 years ago in #730. Before, it wasbuilding an inference context to be able to call
can_eqto compare the types. Therustc-dev-guidehas some more detailsabout
can_eqin Type Inference -> Trying equality.Now, using the rustc function, we are essentially comparing the
DefIdsof 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