Repository navigation
Replace manual use of index newtypes bundles[bundle.index()] with Index impls and typed Vec wrappers #62
Description
Activity
Could we just use
cranelift-entityfor this?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.
Yeah I'd be hesitant to introduce a circular dependency in general between repositories. (Perhaps
cranelift-entityreally should be its own little independent library, but that's a slightly bigger question...)Or
regalloc2should be undercranelift/in the Wasmtime repo.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!)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-entityoutside of Cranelift, for my own compiler.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.
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.
I don't think that works when one of the versions is from crates.io and the other is a path dependency.
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.
Right now, regalloc2 uses an entity-component-system sort of pattern with toplevel
Vecs ofLiveBundle,VRegData, and the like, and newtype'd index wrappers likeLiveBundleIndex,VRegIndex, etc. We have a whole bunch of instances ofself.bundles[bundle.index()]....Ideally we would make
bundlesaVec-wrapper type that has anIndeximplementation that natively takesLiveBundleIndex, and then we could make all of these sites slightly less verbose.