Repository navigation
Rollup of 9 pull requests - #165313
Rollup of 9 pull requests#165313
Conversation
``` error[E0425]: cannot find function `bar` in this scope --> $DIR/suggest-self-2.rs:9:9 | LL | bar(&&self, 102); | ^^^ | help: try calling `bar` as a method | LL - bar(&&self, 102); LL + self.bar(102); | ```
The old message, “help: use `let _ = ...` to ignore the resulting value” (or its variation with `let _unused` for `needs_drop` values), contains no indication that this is something that you might not want to do, and in fact can be read as saying that one *should* do this. The new message, “if you wish to disregard this recommendation, use `let _ = ...` to ignore the value”, is intended to make it clear that this is a choice.
* Add regression test * Recover inner attributes in algebraic data types * Try to recover after every field and variant
We should not forbid users from experimenting on their own forks. https://x.com/0xalpharush/status/2116964999000478125
… r=fmease
Recover inner attributes in algebraic data types
Previously, if you'd put an inner attribute in an empty ADT, such as a struct:
```rust
struct Test1 {
#![inline]
}
```
You'd get the following errors
```
error: an inner attribute is not permitted in this context
--> src/lib.rs:5:5
|
5 | #![cfg(false)]
| ^^^^^^^^^^^^^^
|
= note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files
= note: outer attributes, like `#[test]`, annotate the item following them
error: expected identifier, found `}`
--> src/lib.rs:6:1
|
4 | struct Test3 {
| ----- while parsing this struct
5 | #![cfg(false)]
6 | }
| ^ expected identifier
error: could not compile `rust-test` (lib) due to 2 previous errors
```
The second error is spurious. It was caused by us only recovering inner attributes just before parsing a field, meaning if we see an inner attribute and recover we expect a field next. This PR fixes that by recovering inner attributes just after the curly brace as well.
Make the suggestion message of `unused_must_use` scarier. The old message, “help: use `let _ = ...` to ignore the resulting value”, contains no indication that this is something that you might not want to do, and in fact can be read as saying that one *should* do this. The new message, “help: if you wish to disregard this recommendation and immediately drop the value, use `let _ = ...`”, is intended to make it clear that this is a choice, and choosing it has the particular effect of immediately dropping the value. A possible further improvement, not part of this change, might be to distinguish between types that are `must_use` and have a destructor (whose side-effects are likely relevant), and types that are `must_use` and do not have a destructor, where the timing is irrelevant and the consequence is just ignoring information that was provided. However, not every destructor is relevant to `must_use`; for example, `Result<(), Box<dyn Error>>` has a destructor and is `must_use`, but the destructor is only managing memory for the error value and it has no side effects relevant to the caller (unless the error in the box has side effects of its own). Inspired by [#t-lang > Lint for assigning drop guards to _](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Lint.20for.20assigning.20drop.20guards.20to.20_/with/624036822) @rustbot label +A-lints +L-unused_must_use
…mease
Use verbose suggestion for type literal with wrong syntax
```
error[E0423]: cannot find value `StructWithFields` in crate `xcrate_unit_struct`
--> $DIR/unit-struct.rs:9:33
|
LL | let _ = xcrate_unit_struct::StructWithFields;
| ^^^^^^^^^^^^^^^^
|
::: $DIR/auxiliary/xcrate_unit_struct.rs:20:1
|
LL | pub struct StructWithFields {
| --------------------------- `xcrate_unit_struct::StructWithFields` defined here
|
= note: a struct named `xcrate_unit_struct::StructWithFields` exists in another namespace
help: use struct literal syntax instead
|
LL | let _ = xcrate_unit_struct::StructWithFields { foo: val };
| ++++++++++++
```
```
error[E0532]: expected tuple struct or tuple variant, found unit variant `Color::NoColor`
--> $DIR/match-pattern-field-mismatch-2.rs:12:11
|
LL | enum Color {
LL | NoColor,
| ------- `Color::NoColor` defined here
...
LL | Color::NoColor(_) => { }
| ^^^^^^^^^^^^^^^^^
|
help: use the unit struct syntax instead
|
LL - Color::NoColor(_) => { }
LL + Color::NoColor => { }
|
```
…tern-comma-suggestion, r=fmease Fix multiple pattern comma suggestions in diagnostics `skip_pat_list` and `recover_unexpected_comma` is on cold path, so there will be no perf issue here.
…d-qualifications-wildcard, r=fmease Don't lint unused_qualifications when the unqualified path is ambiguous Fixes rust-lang#163310
Improve span for unused_mut lint Closes rust-lang#165269 I basically used trim to avoid the overlap of spans mentioned on the issue. I kept the whitespace in the "mut" span since the fix removes the whole span and not removing the whitespace would mean for uglier code after fix. If this is really important, I could add an extra span to the diagnostic struct, but I'll wait on feedback.
…gjubilee Forward `AbiAlign` `Debug` impl to `Align` The `Debug` output of `AbiAlign` shows up in UI test stderr output via `LayoutData`. The first commit of this PR changes `Debug` impl of `AbiAlign` to directly forward to `Align`, meaning that the future change from `AbiAlign` to `Align` won't affect test output. The second commit removes unused `//@ normalize-stderr` directives for preferred alignment. Commits are easiest to review individually - most of the changes are just blessing tests. r? @workingjubilee
…ecks-desc, r=chenyukang unstable.rs: add missing `]` in description of `cfg_ub_checks`
…=jieyouxu Clarify AGENTS.md around pushing to a fork We should not forbid users from experimenting on their own forks. https://x.com/0xalpharush/status/2116964999000478125 r? @jyn514
|
@bors r+ p=5 force |
This comment has been minimized.
This comment has been minimized.
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 48dfc3a (parent) -> 2a01bd6 (this PR) Test differencesShow 29 test diffsStage 1
Stage 2
Additionally, 20 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 2a01bd6f8ba2b81badc578a7fa927d4ff00f8c71 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (2a01bd6): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)Results (primary -2.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis perf run didn't have relevant results for this metric. Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 485.919s -> 487.539s (0.33%) |
|
📌 Perf builds for each rolled up PR:
parent commit: 48dfc3a4e0 In the case of a perf regression, run the following command with the SHAs of each PR you suspect might be the cause: |
Successful merges:
unused_must_usescarier. #162819 (Make the suggestion message ofunused_must_usescarier.)AbiAlignDebugimpl toAlign#165285 (ForwardAbiAlignDebugimpl toAlign)]in description ofcfg_ub_checks#165294 (unstable.rs: add missing]in description ofcfg_ub_checks)r? @ghost
Create a similar rollup