Remove support for prefix yield

[eholk]

Part of the proposal in rust-lang/rfcs#3861 is to go forward with the postfix version of yield. This PR updates rustc to match that design.

This is currently a draft PR. Its main value at this point is to give people a feel for postfix yield by seeing how the test cases and examples change.

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

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

    Uninstalling pip-25.2:
      Successfully uninstalled pip-25.2
Successfully installed pip-25.3
linting python files
error: Failed to parse /checkout/library/core/src/unicode/printable.py:20:32: Expected an identifier, but found a keyword 'yield' that cannot be used here
/checkout/library/core/src/unicode/printable.py:20:32: E999 SyntaxError: Expected an identifier, but found a keyword 'yield' that cannot be used here
Found 1 error.

python linting failed! Printing diff suggestions:
error: Failed to parse /checkout/library/core/src/unicode/printable.py:20:32: Expected an identifier, but found a keyword 'yield' that cannot be used here
tidy [extra_checks]: checks with external tool 'ruff' failed
tidy [extra_checks]: FAIL
tidy: The following check failed: extra_checks
Bootstrap failed while executing `test src/tools/tidy tidyselftest --extra-checks=py,cpp,js,spellcheck`
Command `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools-bin/rust-tidy /checkout /checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo /checkout/obj/build 4 /node/bin/npm --extra-checks=py,cpp,js,spellcheck` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1549:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1280:29

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:01:20
  local time: Fri Oct 31 01:11:37 UTC 2025
  network time: Fri, 31 Oct 2025 01:11:37 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[ds84182]

I actually dislike the postfix syntax quite a lot. I think yield, being a form of control flow, should match break. ().yield; just looks strange.

[Kobzol]

The ship has probably sailed for break, but note that await is already a postfix control-flow operator, which is very related to yield (and in fact it desugars into yield), so it IMO makes sense to also use postfix for it.

Note that if we ever get generators that can receive responses from the caller after being resumed, then yield will have a return value, same as await, so it would be very useful to be able to chain it, for the same reasons as await.

[estebank]

Could we keep the parse, creating an error expression kind with an appropriate suggestion for the postfix?

Ideally, if maintenance cost wasn't a thing, we'd keep the yield kind too, for later more complex diagnostics, but at the very least we should be able to parse yield foo to tell people to use foo.yield instead (like we already do for await foo).

We're diverging from other language's syntax. Without an explicit check, we'd end up with something like:

error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `foo`
 --> src/lib.rs:2:9
  |
2 |     yield foo;
  |           ^^^ expected one of 8 possible tokens
  |
help: you might have meant to write a field access
  |
2 |     yield.foo;
  |          +

[eholk]

Oh, that's a great idea! I'll add that back in before I mark this PR as ready to review.

[PatchMixolydic]

Postfix yield does feel kind of awkward for generators, but operating under the hope assumption that coroutines with resume args will eventually reach stable, it'd be much better than having to parenthesize prefix yield in chains, or having two nearly-identical forms of yield expressions.

Still, it seems like it'd be much better to retain bare yield as sugar for ().yield, partly for consistency with return and partly to make writing state machines with no useful Coroutine::Yield/Iterator::Item type more ergonomic (though I'm not sure how much of a concern this is in practice ^^;).

[clarfonthey]

The ship has probably sailed for break

Has it, though? Would it not be possible to support postfix break and return while still preserving support for the prefix versions before an edition bump?

I think that it's very fair to propose a suffix version and implement it, but I also think that it's very premature to remove the prefix version in the same change. And I think that if we're going along with suffix control flow keywords moving forward, there should probably be an RFC to propose doing so with existing keywords (break and return) rather than just shrugging and saying that it's okay to be prefix sometimes and suffix other times, based upon vibes alone.