-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sync rustfmt subtree #98040
Sync rustfmt subtree #98040
Conversation
…ust-lang#5217) * fix(rustfmt): fix struct field formatting with doc comments present Fixes rust-lang#5215 * fix review feedbacks * add unit test without doc comment * move tests to a seperate file * add additional test cases * reintroduce a newline at the of test/souce/structs.rs
* bump deps * sort the deps
`MultiSpan` contains labels, which are more complicated with the introduction of diagnostic translation and will use types from `rustc_errors` - however, `rustc_errors` depends on `rustc_span` so `rustc_span` cannot use types like `DiagnosticMessage` without dependency cycles. Introduce a new `rustc_error_messages` crate that can contain `DiagnosticMessage` and `MultiSpan`. Signed-off-by: David Wood <david.wood@huawei.com>
This commit updates the signatures of all diagnostic functions to accept types that can be converted into a `DiagnosticMessage`. This enables existing diagnostic calls to continue to work as before and Fluent identifiers to be provided. The `SessionDiagnostic` derive just generates normal diagnostic calls, so these APIs had to be modified to accept Fluent identifiers. In addition, loading of the "fallback" Fluent bundle, which contains the built-in English messages, has been implemented. Each diagnostic now has "arguments" which correspond to variables in the Fluent messages (necessary to render a Fluent message) but no API for adding arguments has been added yet. Therefore, diagnostics (that do not require interpolation) can be converted to use Fluent identifiers and will be output as before.
Extend loading of Fluent bundles so that bundles can be loaded from the sysroot based on the language requested by the user, or using a nightly flag. Sysroot bundles are loaded from `$sysroot/share/locale/$locale/*.ftl`. Signed-off-by: David Wood <david.wood@huawei.com>
Add an option for enabling and disabling Fluent's directionality isolation markers in output. Disabled by default as these can render in some terminals and applications. Signed-off-by: David Wood <david.wood@huawei.com>
refactor: rename some private whitelist names
Loading the fallback bundle in compilation sessions that won't go on to emit any errors unnecessarily degrades compile time performance, so lazily create the Fluent bundle when it is first required. Signed-off-by: David Wood <david.wood@huawei.com>
Create (unstable) 2024 edition [On Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Deprecating.20macro.20scoping.20shenanigans/near/272860652), there was a small aside regarding creating the 2024 edition now as opposed to later. There was a reasonable amount of support and no stated opposition. This change creates the 2024 edition in the compiler and creates a prelude for the 2024 edition. There is no current difference between the 2021 and 2024 editions. Cargo and other tools will need to be updated separately, as it's not in the same repository. This change permits the vast majority of work towards the next edition to proceed _now_ instead of waiting until 2024. For sanity purposes, I've merged the "hello" UI tests into a single file with multiple revisions. Otherwise we'd end up with a file per edition, despite them being essentially identical. ````@rustbot```` label +T-lang +S-waiting-on-review Not sure on the relevant team, to be honest.
The v2 implementation uses Node 12, which is end-of-life on April 30, 2022. See https://nodejs.org/en/about/releases/. Update to v3, which is based on Node 16 whose support lasts until April 30, 2024.
Signed-off-by: cuishuang <imcusg@gmail.com>
It's unclear which PR resolved this issue, however the behavior of adding inline comments to the next line can't be reproduced. These test cases should serve to prevent a regression.
Fixes rust-lang#5260 by checking if it is part of a type '::'
These seem to have no useful effect... they don't seem useful from a code inspection point of view, and they affect anything in the test suite.
…cks, r=Aaron1011 Remove hacks in `make_token_stream`. `make_tokenstream` has three commented hacks, and a comment at the top referring to rust-lang#67062. These hacks have no observable effect, at least as judged by running the test suite. The hacks were added in rust-lang#82608, with an explanation [here](rust-lang#82608 (comment)). It appears that one of the following is true: (a) they never did anything useful, (b) they do something useful but we have no test coverage for them, or (c) something has changed in the meantime that means they are no longer necessary. This commit removes the hacks and the comments, in the hope that (b) is not true. r? `@Aaron1011`
@bors r+ |
📌 Commit f367f4d has been approved by |
⌛ Testing commit f367f4d with merge 656832b3bf5fe7a19e3d628870a174326ac8280b... |
This comment has been minimized.
This comment has been minimized.
💥 Test timed out |
At first blush I'm a bit surprised this only occurred on some platforms and not others, but regardless I don't think it's transient. Will take a closer look later today @bors r- |
@calebcartwright for what it's worth I also ran into a clap issue a little while ago when opening up a PR. I think I have a fix in rust-lang/rustfmt#5385, but not totally sure if that will be an acceptable solution for what's going on here |
Thanks @ytmimi though I think this is probably just a case of needing the features specified as part of the workspace hack in this repo |
Perhaps you should bump clap to 3.1.18 too https://github.com/clap-rs/clap/blob/524e36cf1a67ee6a447d3615a70b065d2b4f5e60/Cargo.toml#L122
|
We can take a look at rustfmt items over in r-l/rustfmt, but I don't think the precise version will be all that relevant here nor would I expect it to address the failure because rustfmt is using the derive feature, while other clap consumers are not. That's fine for individual builds in respective tool repos, but ends up being problematic in this repository for reasons best explained in https://github.com/rust-lang/rust/tree/master/src/tools/rustc-workspace-hack#rustc-workspace-hack. |
@bors r+ p=1 Subtree sync and would like to reduce risk of merge conflicts and having to restart the process |
📌 Commit 3733e45 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (a2ecbf8): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
No description provided.