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_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