Make SpanlessEq more consistent

[gernot-ohner]

1. Remove wildcard as requested in Make SpanlessEq more consistent #10267.
2. Implement hir_utils::eq_expr for ExprKind::Closure, ExprKind::ConstBlock, ExprKind::InlineAsm and ExprKind::Yield.
3. Reorder branches of hir_utils::eq_expr to be in alphabetical order.

---

changelog: none

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @dswij (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[flip1995]

This LGTM overall. It even uncovered an unimplemented kind IIUC. Is there a reason why this is still in draft mode?

If you want you can do the same for the SpanlessHash implementation of Expr. They should be always in sync anyway.

[gernot-ohner]

Thanks for the review!

I wasn't sure whether the implementation of the branch for Yield was correct in ignoring comparing the expression and ignoring the YieldSource. My impression is that that's correct, but I'd defer to your opinion here.

I'm also unsure what the preferred procedure is: Should I create another PR for the changes in SpanlessHash or it in this one?

[dswij]

I'm also unsure what the preferred procedure is: Should I create another PR for the changes in SpanlessHash or it in this one?

If the scope isn't too big, and it's (kinda) related like this one, I'd say it's fine to do it in one PR.

But doing it in separate PRs is not really a problem as well

Just let us know :)

[gernot-ohner]

In that case, I'd like to do it in a separate PR.
Is this PR ready to be merged then? Or would you like to have anything else done here?

[flip1995]

Should I create another PR for the changes in SpanlessHash or it in this one?

As the implementations of Hash an Eq should always agree (std::Hash), I'd prefer to do this as an additional commit in this PR.

[flip1995]

Just noticed that hash_expr already was complete. Thanks for doing the plumbing work of sorting it anyway.

[flip1995]

@bors r+

[bors]

📌 Commit 171845d has been approved by flip1995

It is now in the queue for this repository.

[bors]

⌛ Testing commit 171845d with merge ba43632...

[bors]

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: flip1995
Pushing ba43632 to master...