Replace manual use of index newtypes `bundles[bundle.index()]` with `Index` impls and typed `Vec` wrappers

[cfallin]

Right now, regalloc2 uses an entity-component-system sort of pattern with toplevel Vecs of LiveBundle, VRegData, and the like, and newtype'd index wrappers like LiveBundleIndex, VRegIndex, etc. We have a whole bunch of instances of self.bundles[bundle.index()]....

Ideally we would make bundles a Vec-wrapper type that has an Index implementation that natively takes LiveBundleIndex, and then we could make all of these sites slightly less verbose.

[Amanieu]

Could we just use cranelift-entity for this?

[bjorn3]

That would likely require moving cranelift-entity out of the wasmtime repo and independently versioning it. Otherwise you are pretty much stuck with two copies in case you are compiling cranelift.

[cfallin]

Yeah I'd be hesitant to introduce a circular dependency in general between repositories. (Perhaps cranelift-entity really should be its own little independent library, but that's a slightly bigger question...)

[fitzgen]

Or regalloc2 should be under cranelift/ in the Wasmtime repo.

[cfallin]

That's a much bigger discussion as well... at the time at least, we had good reasons to not do that: different (lighter-weight) CI here, historical precedent wrt regalloc.rs, general modularity (I would argue by default separable libraries should be separate, and the burden of argument is on the consolidation side, but that's of course subjective...). I'm not completely opposed to it now but that's a big thing to re-consider especially now that it's established, others have forked and contributed, may have direct references to it. Basically subsuming the whole repo into another one feels out of proportion to the upside "can use a nice indexing type". (Of course if anyone feels strongly about this they're welcome to create a toplevel issue for it!)

[Amanieu]

That would likely require moving cranelift-entity out of the wasmtime repo and independently versioning it. Otherwise you are pretty much stuck with two copies in case you are compiling cranelift.

Is this resolved by the upcoming Wasmtime 1.0 release?

FWIW I'm already using cranelift-entity outside of Cranelift, for my own compiler.

[bjorn3]

If regalloc2 were to use cranelift-entity as is, you would get two copies of cranelift-entity. One used by regalloc2 from crates.io and one used by cranelift part of this repo.

[Amanieu]

Not if cranelift-entity was 1.0, since the 2 uses would be semver-compatible and Cargo would satisfy both of them with a single dependency version.

[bjorn3]

I don't think that works when one of the versions is from crates.io and the other is a path dependency.

[cfallin]

The switch to 1.0-series versions (bumping major number at each release) don't change anything here, I think; the plan is still for each release to be a semver bump wrt the last one.