Rollup of 8 pull requests #137093
Merged
Rollup of 8 pull requests #137093
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This removes support for attributes on struct field rest patterns (the `..`) from the parser. Previously they were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.
Gets rid of two top-level UI tests which is always great. Furthermore, move `need-crate-arg-ignore-tidy$x.rs` from `command/` to `invalid-compile-flags/`. `command/` concerns `std::process::Command` tests, not CLI tests.
…r=bjorn3
Fix crate name validation
Reject macro calls inside attribute `#![crate_name]` like in `#![crate_name = concat!("na", "me")]`.
Prior to rust-lang#117584, the result of the expansion (here: `"name"`) would actually be properly picked up by the compiler and used as the crate name. However since rust-lang#117584 / on master, we extract the "value" (i.e., the *literal* string literal) of the `#![crate_name]` much earlier in the pipeline way before macro expansion and **skip**/**ignore** any `#![crate_name]`s "assigned to" a macro call. See also rust-lang#122001.
T-lang has ruled to reject `#![crate_name = MACRO!(...)]` outright very similar to other built-in attributes whose value we need early like `#![crate_type]`. See accepted FCP: rust-lang#122001 (comment).
Note that the check as implemented in this PR is even more "aggressive" compared to the one of `#![crate_type]` by running as early as possible in order to reject `#![crate_name = MACRO!(...)]` even in "non-normal" executions of `rustc`, namely on *print requests* (e.g., `--print=crate-name` and `--print=file-names`). If I were to move the validation step a bit further back close to the `#![crate_type]` one, `--print=crate-name` (etc.) would *not* exit fatally with an error in this kind of situation but happily report an incorrect crate name (i.e., the "crate name" as if `#![crate_name]` didn't exist / deduced from other sources like `--crate-name` or the file name) which would match the behavior on master. Again, see also rust-lang#122001.
I'm mentioning this explicitly because I'm not sure if it was that clear in the FCP'ed issue. I argue that my current approach is the most reasonable one. I know (from reading the code and from past experiments) that various print requests are still quite broken (mostly lack of validation).
To the best of my knowledge, there's no print request whose output references/contains a crate *type*, so there's no "inherent need" to move `#![crate_type]`'s validation to happen earlier.
---
Fixes rust-lang#122001.
https://github.com/rust-lang/rust/labels/relnotes: Compatibility. Breaking change.
…s, r=compiler-errors Do not allow attributes on struct field rest patterns Fixes rust-lang#81282. This removes support for attributes on struct field rest patterns (the `..` bit) from the parser. Previously any attributes were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt. This needs an equivalent change to the reference but I wanted to see how this PR is received first. The error message it produces isn't great, however it does match the error you get if you try to add attributes to .. in struct expressions atm, although I can understand wanting to do better given this was previously accepted. I think I could move attribute parsing back up to where it was and then emit a specific new error for this case, however I might need some guidance as this is the first time I've messed around inside the compiler. While this is technically breaking I don't think it's much of an issue: attributes in this position don't currently do anything and rustfmt outright deletes them, meaning it's incredibly unlikely to affect anyone. I have already made the equivalent change to *add* support for attributes (mostly) but the conversation in the linked issue suggested it would be more reasonable to just remove them (and pointed out it's much easier to add support later if we realise we need them).
…or-129273, r=estebank Try to recover from path sep error in type parsing Fixes rust-lang#129273 Error using `:` in the argument list may mess up the parser. case `tests/ui/suggestions/struct-field-type-including-single-colon` also changed, seems it's the same meaning, should be OK. r? `@estebank`
…older-logic, r=notriddle rustdoc: Properly restore search input placeholder Fix the search input placeholder literally getting set to the string *undefined* on blur/defocus. This was caused by us trying to access an undefined property in the event listener. To prevent this from regressing again, stop typescript from ignoring the relevant site. Steps to reproduce the bug fixed in this PR: 1. Focus the search input field by clicking on it and clear the input if necessary 2. Blur/defocus it by clicking somewhere outside of it --- First bug that would've been caught by TSC if we had had it earlier! Type (quasi-)safety, ahoy! :)
…r=aDotInTheVoid fix(rustdoc): Fixed `Copy Item Path` in rust doc This PR aims to address the issue reported by rust-lang#137048 Issue caused by previous changes for removing `@ts-expect-error` by this change rust-lang@2ea95f8
…marcoieni Do not generate invalid links in job summaries Avoid [this](https://github.com/rust-lang-ci/rust/actions/runs/13341911341#summary-37267605606). It has bugged me for quite some time :) When a directory is empty, the `*.xz` bash glob "expands" to a file called `*.xz`. r? `@marcoieni`
compiletest: add `{ignore,only}-rustc_abi-x86-sse2` directives
As requested in https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/compiletest.20target.20selection.20is.20way.20too.20rigid, cc `@RalfJung`
r? bootstrap (or compiler)
…, r=jieyouxu triagebot.toml: ping me on changes to `tests/rustdoc-json`
rustbot
added
A-compiletest
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 15, 2025
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#127581 (Fix crate name validation) - rust-lang#136490 (Do not allow attributes on struct field rest patterns) - rust-lang#136808 (Try to recover from path sep error in type parsing) - rust-lang#137055 (rustdoc: Properly restore search input placeholder) - rust-lang#137068 (fix(rustdoc): Fixed `Copy Item Path` in rust doc) - rust-lang#137070 (Do not generate invalid links in job summaries) - rust-lang#137074 (compiletest: add `{ignore,only}-rustc_abi-x86-sse2` directives) - rust-lang#137076 (triagebot.toml: ping me on changes to `tests/rustdoc-json`) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: e72df78268 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (500a686): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -1.4%, secondary -1.3%)This 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.
CyclesResults (primary -2.6%, secondary 2.7%)This 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 790.103s -> 789.592s (-0.06%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Copy Item Pathin rust doc #137068 (fix(rustdoc): FixedCopy Item Pathin rust doc){ignore,only}-rustc_abi-x86-sse2directives #137074 (compiletest: add{ignore,only}-rustc_abi-x86-sse2directives)tests/rustdoc-json#137076 (triagebot.toml: ping me on changes totests/rustdoc-json)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup