fix(rustdoc): Fixed `Copy Item Path` in rust doc
This PR aims to address the issue reported by https://github.com/rust-lang/rust/issues/137048
Issue caused by previous changes for removing `@ts-expect-error` by this change 2ea95f8670
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! :)
Try to recover from path sep error in type parsing
Fixes#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`
Do not allow attributes on struct field rest patterns
Fixes#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).
Fix crate name validation
Reject macro calls inside attribute `#![crate_name]` like in `#![crate_name = concat!("na", "me")]`.
Prior to #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 #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 #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: https://github.com/rust-lang/rust/issues/122001#issuecomment-2023203182.
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 #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#122001.
https://github.com/rust-lang/rust/labels/relnotes: Compatibility. Breaking change.
Update cargo
13 commits in 2928e32734b04925ee51e1ae88bea9a83d2fd451..ce948f4616e3d4277e30c75c8bb01e094910df39
2025-02-07 16:50:22 +0000 to 2025-02-14 20:32:07 +0000
- util: provide a better error message for invalid SSH URLs (rust-lang/cargo#15185)
- Fix the description of the `"root"` field of the `cargo metadata`'s output (rust-lang/cargo#15182)
- refactor: Consolidate creation of SourceId from manifest path (rust-lang/cargo#15172)
- docs(embedded): Note the shebang deviation (rust-lang/cargo#15173)
- refactor(embedded): Integrate cargo-script logic into main parser (rust-lang/cargo#15168)
- feat: implement workspace feature unification (rust-lang/cargo#15157)
- Fix race condition in panic_abort_tests (rust-lang/cargo#15169)
- Update all dependencies (rust-lang/cargo#15166)
- Update curl from 8.9.0 to 8.12.0 (rust-lang/cargo#15162)
- Update annotate-snippets from 0.11.4 to 0.11.5 (rust-lang/cargo#15165)
- Update deny.toml (rust-lang/cargo#15164)
- Update rusqlite from 0.32.1 to 0.33.0 (rust-lang/cargo#15163)
- fix: align first line of unordered list with following (rust-lang/cargo#15161)
Do more lazy-formatting in `librustdoc` 🦥
Modify some formatting to be lazy, i.e. to not allocate interim strings that are later formatted into different strings.
Commits are small and stand on their own, and should mostly compile separately. (The first one doesn't compile due to `dead_code` because all it does is introduce a helper used in later commits)
Really excited about this one, local perf results are really good. I'd love a perf run to see how this looks on CI. This is the comparison of `instructions:u` count between master and this PR, on my computer:
# Summary
| | Range | Mean | Count |
|:---:|:---:|:---:|:---:|
| Regressions | - | 0.00% | 0 |
| Improvements | -8.03%, -0.40% | -2.93% | 5 |
| All | -8.03%, -0.40% | -2.93% | 5 |
# Primary benchmarks
| Benchmark | Profile | Scenario | % Change | Significance Factor |
|:---:|:---:|:---:|:---:|:---:|
| typenum-1.17.0 | doc | full | -8.03% | 40.16x |
| nalgebra-0.33.0 | doc | full | -4.19% | 20.97x |
| stm32f4-0.14.0 | doc | full | -1.35% | 6.73x |
| libc-0.2.124 | doc | full | -0.67% | 3.33x |
| cranelift-codegen-0.82.1 | doc | full | -0.40% | 1.99x |
Forward all default methods for I/O impls
Forward all default methods for `&mut T` and `Box<T>` to the inner `io::Read`, `io::Write`, `io::Seek`, and `io::BufRead` types.
mir_build: Clarify some code for lowering `hir::PatExpr` to THIR
A few loosely-related improvements to the code that lowers certain parts of HIR patterns to THIR.
I was originally deferring this until after #136529, but that PR probably won't happen, whereas these changes should hopefully be uncontroversial.
r? Nadrieril or reroll
Windows: Update generated bindings
Update to windows-bindgen 0.59.
This update is aimed at reducing churn in the future, but means a bit more churn now:
- `bindings.txt` no longer needs us to write the namespace for each item. This is good because it means in the future we won't need to change them if the namespace changes. However, there are a few where we still need to disambiguate due to duplicate items (this is a bug in the upstream metadata).
- The output in `windows-sys.rs` is now sorted. It was mostly sorted before but not intentionally. This should mean future changes are less noisy.
The actual code changes are minimal here. A few types are now `bool` instead of `BOOLEAN`, which is more convenient.
Implement Extend<AsciiChar> for String
Implement `Extend<AsciiChar>` for `String` as suggested in https://github.com/rust-lang/rust/issues/110998#issuecomment-2590122968. Also implements `Extend<&AsciiChar>` since there's an analogous impl for `Extend<&char>`, but happy to remove if not thought useful.
r? `@scottmcm`
since you requested it, but no pressure to review!
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.
