-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rollup of 8 pull requests #110249
Rollup of 8 pull requests #110249
Conversation
For a common pattern.
There's a bad pattern matching confusion present in this function. `_anon` gets assigned to, and then `_anon` is used as an unbound variable in the pattern, which is unrelated to the first `_anon`. If the `_anon` didn't start with `_` the compiler would give warnings. This was introduced in rust-lang#104239. I have rewritten the function to remove the confusion and preserve the existing behaviour. This seems safest, because the original intent is not clear.
Adds a link to the relevant part of The Rust Reference in the eror message, and suggests a possible fix (replacing the fragment specifier with :tt in the macro definition). Fixes typos in the original message. Signed-off-by: Lena Milizé <me@lvmn.org>
And wrap the link in the diagnostic in angle brackets. Signed-off-by: Lena Milizé <me@lvmn.org>
This is very dependent on subjectivity and what screen you use, but this change makes the radio buttons' outer circle less ugly. This is because I could see the pixels very clearly, thanks to the very thin line and high contrast. This change makes both less severe, giving your browser's antialiasing algorithm more to work with. Since it's thicker, lowering the contrast shouldn't impact visibility.
Fixes the desktop scrolling weirdness mentioned in rust-lang#98775 (comment) As described in the MDN page for this property: * The current Firefox ESR is 102, and the first Firefox version to support this feature is 59. * The current Chrome version 112, and the first version to support this is 63. * Edge is described as having a minor bug in `none` mode, but we use `contain` mode anyway, so it doesn't matter. * Safari 16, released September 2022, is the last browser to add this feature, and is also the oldest version we officially support.
Fix typos in compiler I ran [`typos -w compiler`](https://github.com/crate-ci/typos) to fix typos in the `compiler` directory. Refs rust-lang#110150
…avior, r=GuillaumeGomez rustdoc: use CSS `overscroll-behavior` instead of JavaScript Fixes the desktop scrolling weirdness mentioned in rust-lang#98775 (comment) Preview: https://notriddle.com/rustdoc-demo-html-3/overscroll-behavior/issue_107918/index.html As described in the [MDN overscroll-behavior] page: * The current Firefox ESR is 102, and the first Firefox version to support this feature is 59. * The current Chrome version 112, and the first version to support this is 63. * Edge is described as having a minor bug in `none` mode, but we use `contain` mode anyway, so it doesn't matter. * Safari 16, released September 2022, is the last browser to add this feature, and is also the oldest version we officially support. [MDN overscroll-behavior]: https://developer.mozilla.org/en-US/docs/Web/CSS/overscroll-behavior
…kh726 Symbol cleanups r? ```@jackh726``` cc ```@b-naber```
Remove `..` from return type notation `@nikomatsakis` and I decided that using `..` in the return-type notation syntax is probably overkill. r? `@eholk` since you reviewed the last one Since this is piggybacking now totally off of a pre-existing syntax (parenthesized generics), let me know if you need any explanation of the logic here, since it's a bit more complicated now.
…er, r=GuillaumeGomez rustdoc: make settings radio and checks thicker, less contrast This is very dependent on subjectivity and what screen you use, but this change makes the radio buttons' outer circle less ugly. This is because I could see the pixels very clearly, thanks to the very thin line and high contrast. This change makes both less severe, giving your browser's antialiasing algorithm more to work with. Since it's thicker, lowering the contrast shouldn't impact visibility. ## Preview https://notriddle.com/rustdoc-demo-html-3/pixelated-border/settings.html ## Before ![image](https://user-images.githubusercontent.com/1593513/231274191-143acbea-c433-4fb1-b46d-e5e4fe328d60.png) ## After ![image](https://user-images.githubusercontent.com/1593513/231287415-c1e59fe8-8bf8-489d-b607-95ebb71e4ac5.png) <details><summary>Original "after" image with 2px border around checked box</summary> ![image](https://user-images.githubusercontent.com/1593513/231274253-8b5011c6-82fb-4396-84d0-47b6bdff2260.png) </details>
…stic, r=davidtwco Improve the error message when forwarding a matched fragment to another macro Adds a link to [Forwarding a matched fragment](https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment) section of the Rust Reference, and suggests a possible fix (using `:tt` instead in the macro definition). Also removes typos from the original message, it should be `:lifetime` instead of `$lifetime`. ## Motivation When trying to write a macro which uses a literal in the matcher from the outer macro, like the following one, using a fragment specified that isn't one of `:ident`, `:lifetime`, or `:tt` currently results in a hard to understand message. ```rs macro_rules! make_t_for_all_tokens { ($($name:literal as $variant:expr,)*) => { macro_rules! t { $( ($name) => { $variant }; )* } }; } make_t_for_all_tokens! { "fn" as Token::Fn, "return" as Token::Return, "let" as Token::Let, } // This creates // // macro_rules! t { // ("fn") => { // Token::Fn // }; // ("return") => { // Token::Return // }; // ("let") => { // Token::Let // }; // } t!["fn"]; ``` ### Before ``` error: no rules expected the token `"fn"` --> src/main.rs:103:10 | 32 | macro_rules! t { | -------------- when calling this macro ... 103 | t!["fn"]; | ^^^^ no rules expected this token in macro call | note: while trying to match `"fn"` --> src/main.rs:34:6 | 34 | ($name) => { | ^^^^^ ... 58 | / make_t_for_all_tokens! { 59 | | "fn" as Token::Fn, 60 | | "return" as Token::Return, 61 | | "let" as Token::Let, 62 | | } | |_- in this macro invocation = note: captured metavariables except for `$tt`, `$ident` and `$lifetime` cannot be compared to other tokens = note: this error originates in the macro `make_t_for_all_tokens` (in Nightly builds, run with -Z macro-backtrace for more info) ``` ### After ``` error: no rules expected the token `"fn"` --> src/main.rs:103:10 | 32 | macro_rules! t { | -------------- when calling this macro ... 103 | t!["fn"]; | ^^^^ no rules expected this token in macro call | note: while trying to match `"fn"` --> src/main.rs:34:6 | 34 | ($name) => { | ^^^^^ ... 58 | / make_t_for_all_tokens! { 59 | | "fn" as Token::Fn, 60 | | "return" as Token::Return, 61 | | "let" as Token::Let, 62 | | } | |_- in this macro invocation = note: captured metavariables except for `:tt`, `:ident` and `:lifetime` cannot be compared to other tokens = note: see https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment for more information = help: try using `:tt` instead in the macro definition = note: this error originates in the macro `make_t_for_all_tokens` (in Nightly builds, run with -Z macro-backtrace for more info) ``` ## Unresolved questions - Preferrably the suggestion should be attached to the `$name:literal` part of the outer macro, instead of being in the notes section at the end. But I'm not familiar with how the compiler works at all, and I have no idea how to approach this kind of solution. - `@Nilstrieb` raised a question that the suggestion of adding `:tt` isn't accurate when there's more than `tt` being matched, for example when the input is an `item`.
…=jackh726 Split out a separate feature gate for impl trait in associated types in rust-lang#107645 it was decided that we'll take a new route for type alias impl trait. The exact route isn't clear yet, so while I'm working on implementing some of these proposed changes (e.g. in rust-lang#110010) to be able to experiment with them, I will also work on stabilizing another sugar version first: impl trait in associated types. Similarly I'll look into creating feature gates for impl trait in const/static types. This PR does nothing but split the feature gate, so that you need to enable a different feature gate for ```rust impl Trait for Type { type Assoc = impl SomeTrait; } ``` than what you need for `type Foo = impl SomeTrait;`
…ertlarsan68 tidy: Issue an error when UI test limits are too high cc rust-lang#73494 Ensuring the limits are as low as they need to be will make it harder to accidentally add new tests to any large directories
@bors r+ rollup=never p=8 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: 59a05ad118 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (4087dea): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
Successful merges:
overscroll-behavior
instead of JavaScript #110165 (rustdoc: use CSSoverscroll-behavior
instead of JavaScript)..
from return type notation #110203 (Remove..
from return type notation)Failed merges:
ToRegionVid
#110218 (RemoveToRegionVid
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup