Skip to content

Rollup of 2 pull requests - #161582

Merged
rust-bors[bot] merged 6 commits into
rust-lang:mainfrom
jhpratt:rollup-xbqvhjm
Aug 23, 2026
Merged

Rollup of 2 pull requests#161582
rust-bors[bot] merged 6 commits into
rust-lang:mainfrom
jhpratt:rollup-xbqvhjm

Conversation

@jhpratt

@jhpratt jhpratt commented Aug 23, 2026

Copy link
Copy Markdown
Member

Successful merges:

r? @ghost

Create a similar rollup

ArneshBanerjee and others added 6 commits July 31, 2026 17:44
Writing the type of each element inside a tuple pattern like
`let (a: bool, b: u8) = ...` isn't valid, but the current error doesn't
really tell you that. It just says "expected one of `)`, `,`, `@`, `if`,
or `|`, found `:`" and leaves you to work it out.

A let pattern can be followed by a type, so we can suggest the fix: move
the types out into a tuple type after the pattern, so `(a: bool, b: u8)`
becomes `(a, b): (bool, u8)`. Elements without a type just get `_`.
Parsing then keeps going with the types dropped, so you only get the one
error.
Rework the recovery to happen in a single parse instead of parsing the
tuple pattern, resetting on failure, and parsing again. The element
closure now eats an optional `: <ty>` directly, so there's no parser
snapshot on the happy path.

Only treat the colon as a type annotation when it is followed by
whitespace, so `(m:C,)` keeps the existing "maybe write a path separator
here" suggestion for `m::C` and only `(m: C,)` gets the tuple-type
suggestion.
nodelay() passed a null ControlOption to GetModeData, so it always
failed with Unsupported, and it returned the Nagle flag instead of its
negation. The timeout setters accepted a zero Duration that every other
backend rejects.
…ascription, r=fmease

Recover from tuple patterns with inline element types

If you write the element types inside a tuple pattern:

```rust
let (a: bool, b: u8) = (true, 1);
```

the error you get doesn't really explain the problem:

```
error: expected one of `)`, `,`, `@`, `if`, or `|`, found `:`
 --> src/main.rs:2:11
  |
2 |     let (a: bool, b: u8) = (true, 1);
  |           ^ expected one of `)`, `,`, `@`, `if`, or `|`
```

A let pattern can have a type after it, so now we point out what to do instead:

```
help: to annotate the types of a tuple's elements, write them as a tuple type after the pattern
  |
2 -     let (a: bool, b: u8) = (true, 1);
2 +     let (a, b): (bool, u8) = (true, 1);
  |
```

If an element doesn't have a type written, it just gets `_`, so `(a: bool, b)`
turns into `(a, b): (bool, _)`.

I kept this to let bindings only. That's the case where the pattern doesn't need
a type of its own, so once the types move into the suggestion the rest of the
statement parses fine and you get a single error instead of a pile of follow-up
ones. Match arms, nested patterns and function parameters are left alone.

Closes rust-lang#149246
std::net: uefi: fix TcpStream::nodelay and reject zero timeouts

nodelay() passed a null ControlOption to GetModeData, so it always failed with Unsupported, and it returned the Nagle flag instead of its negation. The timeout setters accepted a zero Duration that every other backend rejects.
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Aug 23, 2026
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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. labels Aug 23, 2026
@jhpratt

jhpratt commented Aug 23, 2026

Copy link
Copy Markdown
Member Author

@bors r+ p=4

@rust-bors

rust-bors Bot commented Aug 23, 2026

Copy link
Copy Markdown
Contributor

📌 Commit e7e5017 has been approved by jhpratt

It is now in the queue for this repository.

@rust-bors rust-bors Bot 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 Aug 23, 2026
@rust-bors

This comment has been minimized.

@rust-bors rust-bors Bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 23, 2026
@rust-bors

rust-bors Bot commented Aug 23, 2026

Copy link
Copy Markdown
Contributor

☀️ Test successful - CI
Approved by: jhpratt
Duration: 3h 8m 20s
Pushing 9a4ad59 to main...

@rust-bors
rust-bors Bot merged commit 9a4ad59 into rust-lang:main Aug 23, 2026
14 checks passed
@rustbot rustbot added this to the 1.100.0 milestone Aug 23, 2026
@github-actions

Copy link
Copy Markdown
Contributor
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 be0ea33 (parent) -> 9a4ad59 (this PR)

Test differences

Show 5 test diffs

Stage 1

  • [ui (polonius)] tests/ui/parser/tuple-pattern-type-ascription.rs: [missing] -> pass (J1)
  • [ui] tests/ui/parser/tuple-pattern-type-ascription.rs: [missing] -> pass (J3)

Stage 2

  • [run-make] tests/run-make/compressed-debuginfo-zstd: ignore (ignored if LLVM wasn't build with zstd for ELF section compression or LLVM is not the default codegen backend) -> pass (J0)
  • [ui] tests/ui/parser/tuple-pattern-type-ascription.rs: [missing] -> pass (J2)

Additionally, 1 doctest diff were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 9a4ad59ae3073b013cd62f53f8349ddc61a012e8 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. x86_64-gnu-gcc-core-tests: 1h 20m -> 13m 25s (-83.4%)
  2. x86_64-gnu-stdlib-semver-check: 1h 21m -> 13m 56s (-82.9%)
  3. pr-check-2: 1h 47m -> 33m (-69.2%)
  4. pr-check-1: 1h 43m -> 33m 54s (-67.3%)
  5. x86_64-gnu-gcc: 2h 26m -> 57m 27s (-60.7%)
  6. arm-android: 3h 13m -> 1h 22m (-57.4%)
  7. x86_64-rust-for-linux: 2h 3m -> 54m 20s (-55.9%)
  8. dist-x86_64-solaris: 2h 36m -> 1h 14m (-52.6%)
  9. x86_64-gnu-next-trait-solver-polonius: 1h 58m -> 56m 55s (-52.1%)
  10. x86_64-gnu-miri: 2h 56m -> 1h 27m (-50.5%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup 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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants