Open celinval opened 9 months ago
One possible solution is to revert the crate split that was done before. I believe the main motivation was to ensure we don't use internal constructs inside the Stable APIs. But I think it is easier for us to ensure that this doesn't happen, than ensuring that our users know which things are meant to be public only to the compiler.
I also think it is much easier to make things public later, than the opposite direction.
We have other structures that have the same issue. Not just things that wrap usize.
why not define the types in rustc_smir, then reexport them in stable_mir? that way they can have proper private fields.
generally speaking, types should be defined alongside their constructor.
The current crate structure of StableMIR is making it very hard to properly encapsulate our stable structures. All the internal details of stable items have to somehow be exposed in order to allow
rustc_smir
to build them.For example, the definition of
Ty
exposes its internal representation:There is no mechanism for us today to ensure that this
usize
corresponds to an index inside StableMIR. TheContext
trait is also exposed, even though we expect users to never invoke them directly.The main problems I see with the lack of encapsulation are:
Result
for everything we do.We should investigate what is the best mechanism to fix this.