remove mutability of fn args that don't need it

[matthiaskrgr]

No description provided.

[rustbot]

r? @jackh726

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes might have occurred in exhaustiveness checking

cc @Nadrieril

[jackh726]

This touches a lot more of the codebase than I am comfortable reviewing, I think. It may be a seemingly innocuous change, but there may be cases that the mutability is from past or future change that requires it.

As always with these kind of "change the world" types of changes, I'd rather see some kind of lint that helps to automatically catch these, rather than a one-off change.

[matthiaskrgr]

This is a clippy lint, but we don't run clippy on ci here.

[matthiaskrgr]

I'm not sure if it is a good idea to run clippy on rustc in ci.

Pros:
more coverage for clippy, I have actually a PR up that adds a "run clippy on rustc" to the clippy ci. Rustc has a ton of sophisticated code and this sometimes causes clippy to hang or crash (sometimes caused by changes in clippy, sometimes caused by changes in rustc) and helps catch these bugs early on

you can deny clippy lints in rustc to your hearts content

cons: adding clippy to rustc CI also means, if your rustc change accidentally causes clippy to report FPs on rustc, you will have to fix these as well (inside clippy), to get "green ci" again, which might be a pain (a pro for the clippy team of course :P)

this might add around 5-10 minutes of runtime to rustc ci for the job that also has to run clippy now

right now (there was a pr to change that) you are only guaranteed to run master-clippy on rustc master (versions must match), so you'd have

• build rustc
• build clippy
• run that clippy on rustc again,
  otherwise you might get a ton of compiler errors.

people might start sprinkling allow(clippy::...) around in the rustc code base

[jackh726]

I think approaching this as a "run clippy on rustc" point of view is not a bad approach, and better than this one-off change. For that, an MCP would be good.

For this PR, like I said, I personally don't know that I want to r+ this. You can reroll and see if whoever next disagrees with me, but shrug.

[bors]

☔ The latest upstream changes (presumably #115940) made this pull request unmergeable. Please resolve the merge conflicts.

[jackh726]

I'm going to reassign to another compiler member, because of my thoughts here. Basically, this type of refactoring makes more sense as tool-driven, where there is both a clear criteria for the change and there will be little chance of accidental regressions over time.

r? compiler

[Dylan-DPC]

@matthiaskrgr what's the status of this? thanks

[Dylan-DPC]

Closing this as inactive. Feel free to reöpen this pr or create a new pr if you get the time to work on this. Thanks