Sync rustfmt #98412
Sync rustfmt #98412
Conversation
There was recently an issue where `cargo install` was installing a newer version of a dependency than the one listed in our Cargo.toml. The newer version added deprecation warnings that caused our continuous integration tests to break. As mentioned in the `cargo help install` docs, passing the `--locked` flag should force cargo to use the `Cargo.lock` file included with the repository.
fix sorting of use statements with raw identifiers
There are some proposed import sorting changes for raw identifier `r#`. These changes constitute a breaking change, and need to be version gagted. Before version gating those changes we add the version information to the `UseSegment`.
When useing `version=One` rustfmt will treat the leading `r#` as part of the `UseSegment` used for sorting. When using `version=Two` rustfmt will ignore the leading `r#` and only consider the name of the identifier when sorting the `UseSegment`.
…-warn, r=wesleywiser,flip1995 Support lint expectations for `--force-warn` lints (RFC 2383) Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope. This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust. This will probably conflict with rust-lang#97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix. --- r? `@wesleywiser` cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. 🙃 Follow-up of: rust-lang#87835 Issue: rust-lang#85549 Yeah, and that's it.
* add doc_comment_code_block_width configuration * updated config docu * Updated docu and changed tests to config folder
By setting this value in the Cargo.toml rust-analyzer understands that
rustfmt uses compiler-internals using `extern crate`.
This is a universal step that all developers will need to take in order to
get better type hints and code completion suggestions for
compiler-internals in their editor.
**Note**: users will also need to install the `rustc-dev` component via
`rustup` and add the following to their rust-analyzer configuration:
```json
{
"rust-analyzer.rustcSource": "discover",
"rust-analyzer.updates.channel": "nightly"
}
```
* config_proc_macro: fix failing doctests * ci: include config_proc_macro crate in ci * [review] working native windows ci * [fix] add --locked file for ci * [fix] quoting of cmd variables
Fixes 5399 Memoizing expressions lead to cases where rustfmt's stability guarantees were violated. This reverts commit a37d3ab.
Fixes 5395 In PR 5239 we switched from using `structopt` to `clap`. It seems that the default behavior for `clap` is to override the `--version` flag, which prevented our custom version display code from running. The fix as outlined in clap-rs/clap#3405 was to set `#[clap(global_setting(AppSettings::NoAutoVersion))]` to prevent clap from setting its own default behavior for the `--version` flag.
This reverts commit a37d3ab.
…022-06-22 Subtree sync 2022 06 22
|
Some changes occurred in src/tools/rustfmt. cc @rust-lang/rustfmt |
|
(rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
CI failure was unrelated and transient, closing and reopening to restart the initial CI checks |
|
@bors r+ p=1 subtree sync, and I want to make sure this gets landed before the next nightly build to minimize the number of nightlies containing this bug, as the rustfmt output is supposed to be stable on nightly too |
|
📌 Commit 993ee00 has been approved by |
|
🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened. |
|
@bors retry |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@9cf699d. Direct link to PR: <rust-lang/rust#98412> 🎉 miri on linux: test-fail → test-pass (cc @eddyb @RalfJung @oli-obk).
|
Finished benchmarking commit (9cf699d): comparison url. Instruction count
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
|
I find several of these comments quite confusing. This obviously has no impact on builds/tests for miri, so unclear why the bots believe that updating the rustfmt subtree would. I'm also unsure what the proper etiquette is relative to supposed perf regressions. Similar to the miri comment, rustfmt has absolutely nothing to do with those benchmarks and to the best of my knowledge no aspect of rustfmt is included in those runs. As such I naturally disagree with the assessment, but I'm disinclined to file an issue as that seems like obvious noise. I believe both of these can and should be chalked up to bots running amok, but let me know if anyone feels otherwise |
|
Miri has a spuriously failing test that happened to fail after the previous PR, and happened to work again after this one. The test is fixed in Miri proper but the Miri submodule here still needs updating to prevent such flip-floping of test results. I don't know about the perf changes, but I would ignore them -- I have had perf change reports for Miri updates, which also clearly just demonstrate noise in the perf measurement. |
|
Also @Mark-Simulacrum this might need to be nominated for a backport. This needs to be included in the same release as #98040, so if #98040 is indeed slated for 1.63 as the milestone suggests then I want to nominate this for what I guess is a beta backport |
Mark-Simulacrum
added
beta-nominated
|
beta-accepting for 1.63 backport (mostly as coincidence that these straddled the release cut date) |
…imulacrum [beta] Prepare beta 1.63.0 This PR switches the channel of `beta` after the force-push, and backports the following PRs: * rust-lang#98488 * rust-lang#98412 r? `@ghost`
|
Looks like there is some new noise in the @rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
|
Untagging, re-milestoning, this was included in #98572. |
ehuss
removed
the
beta-nominated
We had a bug in the update we made ~1 week ago, so running a somewhat early sync to pull the fix in