update tests to match lint message changes from rust-lang/rust#140794

[karolzwolak]

Needed for rust-lang/rust#140794 (not merged yet).

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[karolzwolak]

Update:

• Use SNAPSHOTS=overwrite instead of manually blessing the outputs.
• Bump rustfix version
• Leave be old lint message of fake rustc

To be fair, the rustfix tests don't strcitly need the messages to be accurate to pass the tests, they tests the fix suggestions.
I thought the compiler output should be kept in sync in the tests, but I can revert it.

[weihanglo]

Thanks!

[weihanglo]

Could you keep ... so we dont excessively assert too many stuff?

Suggested change

	| ^^^^^^^^^^^^^^^^^^^
	|
	= [NOTE] `#[warn(unused_imports)]` [..]on by default
	[WARNING] `foo` (lib) generated 1 warning (run `cargo fix --lib -p foo` to apply 1 suggestion)
	[FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
	...
	= [NOTE] `#[warn(unused_imports)]` [..]on by default
	...

[weihanglo]

Also, would you mind cleaning up commit like squashing some of them, so it is less confusing when tracing back git history?

[karolzwolak]

Done. Btw why not just squash such PR into 1 commit either using github squash & merge or via some bot?

[weihanglo]

There are meanings in each commit. For example, we follow a variant of the atomic commit pattern especially for bugfix.

Take this https://github.com/rust-lang/cargo/pull/14432/commits as an example. The first commit added a test showing the current problematic behavior. It can be see as a minimal reproducible example to make sure you're fixing a really-existing bug. The next bugfix commit contains both the fix and the test change, so through the test diff you can clearly see the behavior changed.

I know it is a burden on contributors to clean up git history. I can actually do it by myself before merge if the PR allows maintainers to edit. However, sometimes PR author may feel offended like we took their contribution credits. Not sure what the right way is though.

[weihanglo]

Thanks for your help anyway!

[karolzwolak]

Yeah, I can see the appeal of atomic commits, but I'd argue that squashing PR into a single commits has its uses too. If we apply the 'atomic' principle to PRs themselves, the meaningful change is a single commit, and you don’t have to check which PR a commit belongs to.

I just thought it’d be cool to combine both approaches, if commits from a single PR were grouped (like squashed), but you could still see the original commits that make up the PR - not just their names, but the actual revisions and changes too.

I know it is a burden on contributors to clean up git history. I can actually do it by myself before merge if the PR allows maintainers to edit. However, sometimes PR author may feel offended like we took their contribution credits. Not sure what the right way is though.

I think leaving the authors to do the rebasing themselves is the way to go, since you won't really learn unless you do it yourself. Also github keeps the overwritten commits for some time, so it's not like someone can completely overwrite and lose their work.

Thanks too for the quick reviews.