Implement gen blocks in the 2024 edition

[oli-obk]

Coroutines tracking issue #43122
gen block tracking issue #117078

This PR implements gen blocks that implement Iterator. Most of the logic with async blocks is shared, and thus I renamed various types that were referring to async specifically.

An example usage of gen blocks is

fn foo() -> impl Iterator<Item = i32> {
    gen {
        yield 42;
        for i in 5..18 {
            if i.is_even() { continue }
            yield i * 2;
        }
    }
}

The limitations (to be resolved) of the implementation are listed in the tracking issue

[Patryk27]

Nitpicking, but since generators have been renamed to coroutines, shouldn't the block maybe say coro? 👀

[ssokolow]

Nitpicking, but since generators have been renamed to coroutines, shouldn't the block maybe say coro? 👀

I'd find coro misleading because, absent the rest of the word, it looks like it should be pronounced "coh-roh" rather than "coh-roo".

Why not co, as in co fn? (After all, in contexts that had both "subroutines"/"procedures" and "functions", the distinction was generally whether the block of code returned something, and coro fn is sort of rudundant... like "co-routine routine".)

Plus, it'd be reminiscent of Go's go keyword, which exists in service of a similar goal.

[oli-obk]

This PR is specifically only about things that implement Iterator. Which are usually named "generators" in other languages (see https://github.com/oli-obk/rfcs/blob/iter_fn/text/0000-gen-fn.md#prior-art). Full coroutines and syntax for them is something that can be discussed and implemented separately. Although it would be nice to share most syntax with it if that is reasonable, so the interactions need to be discussed.

[oli-obk]

r? @compiler-errors on ba499c7

[bors]

⌛ Testing commit eb66d10 with merge 2cad938...

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 2cad938 to master...

[rust-timer]

Finished benchmarking commit (2cad938): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.1%, 0.2%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[0.1%, 0.2%]	2

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.0%	[0.7%, 1.3%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.4%	[-3.4%, -3.4%]	1
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 635.311s -> 635.194s (-0.02%)
Artifact size: 304.40 MiB -> 304.42 MiB (0.01%)

[voidc]

Shouldn't this say gen fns are not yet implemented?

[oli-obk]

Yes 😅 there's a bunch of diagnostics bugs around gen blocks or functions, but i forgot to give this one a FIXME

[bjorn3]

This breaks Cranelift as fn_sig_for_fn_abi thinks the return type is CoroutineState<u32, ()> but you are actually returning Option<u32>. This kind of breakage has happened before when reworking how async functions worked. #105977 was the fix back then and in particular https://github.com/rust-lang/rust/pull/105977/files#diff-eb5b0fc5c9734679907fdb908c3a6b424ff723c4dceb364eef2588c996366708R111-R132. This doesn't break with LLVM as it doesn't assert type compatibility when assigning values, yet it is still UB for the LLVM backend.

[oli-obk]

Oh. I will not get to this until January. I'd appreciate if someone else picks it up

[bjorn3]

Opened #118219 to fix this.