[Tracking] Language work the core library needs

The language work the core library needs before it can be written. Each item says what in core depends on it and what happens today; the design and the reasoning behind the ordering are in the plan (#520, docs/implementation_plans/core_library.md, Track A). The library itself is tracked by #451.

None of core exists yet. stdlib/core/ has not been created, and all 32 buildable modules in the plan's parity matrix are unstarted. Everything below is runway.

Blocks phase 1

• A1 — a method of a generic impl block is generic too (#521). Was filed in the plan as "bounds on impl generics are ignored"; the cause turned out to have nothing to do with bounds.
• A4 — several trait bounds on one type parameter (#519)
• A5 — the integer operators %, &, |, ^, <<, >> and the compound assignments (#518)
• A2 — default method bodies in traits (#522)
• A3 — generic methods in traits (#523)
• A6 — Copy as a marker trait the move checker honours (#524) — needs a decision first
• A7 — macro_rules in item position (#525)
• A14 — a generic enum built at a method-level type parameter fails LLVM translation (#531)

Blocks phase 2

• A8 — panic, unreachable, todo intrinsics with a message (#526)
• A9 — the for x in iter protocol (#110)
• A10 — associated types in traits (#527)
• A11 — dispatch operators to the core::ops traits (#528)
• A13 — a generic struct with an enum field does not lower (#530)
• A15 — char and str as language types (#532)

Blocks phase 3

• A16 — tuples (#533)
• A17 — slices &[T] and &mut [T] as fat references (#534)
• A18 — const generics on methods. Fell out of A1; the fixture's XFAIL and its commented-out assertions are both gone (#521).
• A19 — Drop (#495)

Not a blocker for any phase

• A12 — an implicit prelude import (#529)
• A20 — if let and ? (#535), item visibility (#489), the missing while loop (#506)

Two things the first items changed

Both are why this list is worth keeping rather than reading the plan once.

A1 was misdiagnosed. The plan blamed a bound being ignored. The same body fails with no bound written at all: a method of a generic impl block had no generics of its own, so the guard that skips a generic function's body never fired and the body was checked with T unbound. The fix closed #487 as well, and emptied KNOWN_BROKEN_STDLIB.

A bound constrains callers, not the body. A generic body is checked after monomorphization against the concrete type, so an unbounded T can already call any method that type has. Worth knowing before writing a core module that relies on a bound to catch a mistake: it will not.

Sizing

A5 was estimated at a day or two and took four commits, because % was the only way to spell an MLIR value name. A1 was estimated as substantial and was a dozen lines. Treat the sizes in the plan as untested until each item is opened.

Start with docs/implementation_plans/core_library.md and the unchecked issue for a specific language prerequisite, such as #522 or #523. Read that issue's reproduction and dependencies before choosing work; this tracking issue is complete only when its selected prerequisite is implemented and its checklist item can be updated.