Skip to content

Rollup of 9 pull requests #143042

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

Closed
wants to merge 23 commits into from

Conversation

matthiaskrgr
Copy link
Member

@matthiaskrgr matthiaskrgr commented Jun 26, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

makai410 and others added 23 commits June 22, 2025 18:01
```
error[E0382]: borrow of moved value: `x`
  --> $DIR/moves-based-on-type-capture-clause-bad.rs:9:20
   |
LL |     let x = "Hello world!".to_string();
   |         - move occurs because `x` has type `String`, which does not implement the `Copy` trait
LL |     thread::spawn(move || {
   |                   ------- value moved into closure here
LL |         println!("{}", x);
   |                        - variable moved due to use in closure
LL |     });
LL |     println!("{}", x);
   |                    ^ value borrowed here after move
   |
   = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value before moving it into the closure
   |
LL ~     let value = x.clone();
LL ~     thread::spawn(move || {
LL ~         println!("{}", value);
   |
```
Suggest cloning `Arc` moved into closure

```
error[E0382]: borrow of moved value: `x`
  --> $DIR/moves-based-on-type-capture-clause-bad.rs:9:20
   |
LL |     let x = "Hello world!".to_string();
   |         - move occurs because `x` has type `String`, which does not implement the `Copy` trait
LL |     thread::spawn(move || {
   |                   ------- value moved into closure here
LL |         println!("{}", x);
   |                        - variable moved due to use in closure
LL |     });
LL |     println!("{}", x);
   |                    ^ value borrowed here after move
   |
   = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value before moving it into the closure
   |
LL ~     let value = x.clone();
LL ~     thread::spawn(move || {
LL ~         println!("{}", value);
   |
```

Fix rust-lang#104232.
Simplify `ObligationCauseCode::IfExpression`

This originally started out as an experiment to do less incremental invalidation by deferring the span operations that happen on the good path in `check_expr_if`, but it ended up not helping much (or at least not showing up in our incremental tests).

As a side-effect though, I think the code is a lot cleaner and there are modest diagnostics improvements with overlapping spans, so I think it's still worth landing.
…eyouxu

make `tidy-alphabetical` use a natural sort

The idea here is that these lines should be correctly sorted, even though a naive string comparison would say they are not:

```
foo2
foo10
```

This is the ["natural sort order"](https://en.wikipedia.org/wiki/Natural_sort_order).

There is more discussion in [#t-compiler/help > tidy natural sort](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/tidy.20natural.20sort/with/519111079)

Unfortunately, no standard sorting tools are smart enough to to this automatically (casting some doubt on whether we should make this change). Here are some sort outputs:

```
> cat foo.txt | sort
foo
foo1
foo10
foo2
mp
mp1e2
np",
np1e2",
> cat foo.txt | sort -n
foo
foo1
foo10
foo2
mp
mp1e2
np",
np1e2",
> cat foo.txt | sort -V
foo
foo1
foo2
foo10
mp
mp1e2
np1e2",
np",
```

Disappointingly, "numeric" sort does not actually have the behavior we want. It only sorts by numeric value if the line starts with a number. The "version" sort looks promising, but does something very unintuitive if you look at the final 4 values. None of the other options seem to have the desired behavior in all cases:

```
  -b, --ignore-leading-blanks  ignore leading blanks
  -d, --dictionary-order      consider only blanks and alphanumeric characters
  -f, --ignore-case           fold lower case to upper case characters
  -g, --general-numeric-sort  compare according to general numerical value
  -i, --ignore-nonprinting    consider only printable characters
  -M, --month-sort            compare (unknown) < 'JAN' < ... < 'DEC'
  -h, --human-numeric-sort    compare human readable numbers (e.g., 2K 1G)
  -n, --numeric-sort          compare according to string numerical value
  -R, --random-sort           shuffle, but group identical keys.  See shuf(1)
      --random-source=FILE    get random bytes from FILE
  -r, --reverse               reverse the result of comparisons
      --sort=WORD             sort according to WORD:
                                general-numeric -g, human-numeric -h, month -M,
                                numeric -n, random -R, version -V
  -V, --version-sort          natural sort of (version) numbers within text
```

r? ``@Noratrieb`` (it sounded like you know this code?)
…links-expansion, r=lolbinarycat

[rustdoc] Do not emit redundant_explicit_links lint if the doc comment comes from expansion

Fixes rust-lang#141553.

The problem was that we change the context for the attributes in some cases to get better error output, preventing us to detect if the attribute comes from expansion. Most of the changes are about keeping track of the "does this span comes from expansion" information.

r? ``@Manishearth``
…ly, r=nnethercote

tests: Do not run afoul of asm.validity.non-exhaustive in input-stats

This addresses one of the three powerpc64-unknown-linux-musl test failures in rust-lang#142280

I was motivated to cover it myself because technically this is also compile-time UB if we compile a program that has `asm!` with x86-64-specific instructions on another platform. That'll only mean something if this is ever switched to build-pass, or if checking emits object code, but conveniently "nop" is valid assembly on all platforms anyone has implemented Rust codegen for. Even the weird ones LLVM doesn't support, like PA-RISC or Common Intermediate Language.

...except GPUs. Not sure about those.

r? ``@nnethercote``
…enkov

Don't  give APITs names with macro expansion placeholder fragments in it

The `DefCollector` previously called `pprust::ty_to_string` to construct a name for APITs (arg-position impl traits). The `ast::Ty` that was being formatted however has already had its macro calls replaced with "placeholder fragments", which end up rendering like `!()` (or ICEing, in the case of rust-lang#140333, since it led to a placeholder struct field with no name).

Instead, collect the name of the APIT *before* we visit its macros and replace them with placeholders in the macro expander. This makes the implementation a bit more involved, but AFAICT there's no better way to do this since we can't do a reverse mapping from placeholder fragment -> original macro call AST.

Fixes rust-lang#140333
StableMIR: Add method to retrieve body of coroutine

It would be handy if we can retrieve body of a coroutine in StableMIR.
…ggestion, r=estebank

Make missing lifetime suggestion verbose

I keep seeing this suggestion when working on rustc, and it's annoying that it's inline. Part of rust-lang#141973. Feel free to close this if there's another PR already doing this.

r? `@estebank`
Fix suggestion spans inside macros for the `unused_must_use` lint

This PR fixes the suggestion spans inside macros for the `unused_must_use` lint by trying to find the oldest ancestor span.

Fixes rust-lang#143025
@rustbot rustbot added A-tidy Area: The tidy tool O-windows Operating system: Windows S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jun 26, 2025
@rustbot rustbot added WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) rollup A PR which is a rollup labels Jun 26, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Jun 26, 2025

📌 Commit ceaa5ea has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 26, 2025
@matthiaskrgr
Copy link
Member Author

@bors p=6

@bors
Copy link
Collaborator

bors commented Jun 26, 2025

⌛ Testing commit ceaa5ea with merge 87ab27b...

bors added a commit that referenced this pull request Jun 26, 2025
Rollup of 9 pull requests

Successful merges:

 - #124595 (Suggest cloning `Arc` moved into closure)
 - #139594 (Simplify `ObligationCauseCode::IfExpression`)
 - #141311 (make `tidy-alphabetical` use a natural sort)
 - #141648 ([rustdoc] Do not emit redundant_explicit_links lint if the doc comment comes from expansion)
 - #142285 (tests: Do not run afoul of asm.validity.non-exhaustive in input-stats)
 - #142393 (Don't  give APITs names with macro expansion placeholder fragments in it)
 - #142884 (StableMIR: Add method to retrieve body of coroutine)
 - #142981 (Make missing lifetime suggestion verbose)
 - #143030 (Fix suggestion spans inside macros for the `unused_must_use` lint)

r? `@ghost`
`@rustbot` modify labels: rollup
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-aux failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@bors
Copy link
Collaborator

bors commented Jun 26, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tidy Area: The tidy tool O-windows Operating system: Windows rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.