layout reader ctx

[onursatici]

Summary

Introduce LayoutReaderContext, a typed-data registry threaded through reader construction so an ancestor layout can publish values that descendant layouts look up by type at construction time.

Breaking: Layout::new_reader and VTable::new_reader gain a &LayoutReaderContext parameter. Out-of-tree impls will get a compile error and must add it

[codspeed-hq]

Merging this PR will improve performance by 13.42%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚡ 2 improved benchmarks
✅ 1273 untouched benchmarks

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Simulation	take_map[(0.1, 1.0)]	1.9 ms	1.7 ms	+16.15%
⚡	Simulation	take_map[(0.1, 0.5)]	1,092.6 µs	986.5 µs	+10.75%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing os/layout-overrides (34bf8aa) with develop (5aa3f3d)}

[joseph-isaacs]

No TypeId please

[onursatici]

would that import bug that hit our use of type id be relevant for this type of use as well? I can use the layout id here, I think it is a bit of a weirder api to have but should work

[joseph-isaacs]

Can we use a Array like Id instead of a TypeId

[gatesn]

What's wrong with TypeId? We use this structure for all ephemeral context objects, i.e. VortexSession.

It works correctly, is very fast, and helps keep it clear that this stuff is never serialized.

The general Id is more used for things that are serialized and then later looked up in a registry on the other end.

[joseph-isaacs]

A type id is not a stable id outside on a single compiler patch version.