Add new "types" map to smir json

[gtrepta]

fixes: #45

This adds a new mapping to the SMIR Json that maps stable_mir::ty:Ty values to their corresponding stable_mir::ty::TyKind values in the context.

[gtrepta]

Looks like there's lots of nondeterminism in various numbers that get assigned to things which breaks the golden tests, even after sorting the types array by the type id.

So far, this is just dumping every type in the visited_tys map, but maybe we can get away for now with paring it down to the elemental types so we can get the semantics working for those.

[jberthold]

We can probably just delete this? (adapting SmirJsonDebugInfo, of course)

Suggested change

types: visited_tys.clone(),

[gtrepta]

I guess so. I only put this here to suppress the compiler from erroring on using an already moved value. This line is on the debug path so I didn't feel the need to think too much about it.

[dkcumming]

I don't really mind what it printed in the debug path, is it handy to have it or is it bloating the output?

[jberthold]

Looks like there's lots of nondeterminism in various numbers that get assigned to things which breaks the golden tests, even after sorting the types array by the type id.

Yes, the problem seems to be that the entries refer to each other, so just sorting by type ID won't straighten everything.
We could try to cut down the changing data by deleting the contents of all TyKind variants that carry Ty fields - still better than no test at all IMHO.

So far, this is just dumping every type in the visited_tys map, but maybe we can get away for now with paring it down to the elemental types so we can get the semantics working for those.

Are there any problems besides the golden tests with the more complex types?
Seems better to keep the extracted information around if it is not getting in the way.

EDIT: However, from looking closer at the CI failures, another issue is AutoTrait and def_id fields in Dynamic entries. The AutoTraits seem to be another interned thing, def_ids are another kind of interning that the compiler uses.
These entries will probably indeed have to be filtered out for now because we are probably missing additional data for those to be useful. Not sure what the resulting shortfall in the semantics will be, but surely we can still execute basic programs 🤞 ).

[dkcumming]

Jost is right, similar to how I removed the other ids with map(del(...)) I think the ids and AutoTrait interned things are going to have the be stripped in the filter (maybe with a comment if it looks particularly arcane)

[gtrepta]

I'm seeing a larger problem than these fields.

The Ty values themselves are showing some instability. So the types array has some nondeterministic key values. Additionally, some enumerations of RigidTy have Ty fields, where different values are also appearing between different runs.

I'm surprised this wasn't an issue before, but it appears as if some Ty values remain stable while others do not.

Here's what I prefer for this PR. TyKind has a predicate called is_primitive which we can use to filter in only the most basic types (u8, isize, etc.) when creating the types array in collect_smir. These appear to have stable Ty values. This gives us something to work with and we can begin introducing other TyKinds one by one when we're ready to implement them and that's when we can work on resolving this instability.

[jberthold]

The Ty values themselves are showing some instability. So the types array has some nondeterministic key values. Additionally, some enumerations of RigidTy have Ty fields, where different values are also appearing between different runs.

Agree. The Ty fields that are in RigidTy variants just compound the problem - the Ty numbers are inherently unreliable because IIUC they get assigned on demand during the compilation.

I'm surprised this wasn't an issue before, but it appears as if some Ty values remain stable while others do not.

Here's what I prefer for this PR. TyKind has a predicate called is_primitive which we can use to filter in only the most basic types (u8, isize, etc.) when creating the types array in collect_smir. These appear to have stable Ty values.

I am not sure whether these are actually stable, TBH, maybe they are just statistically more stable because the base types are used early and often so their Ty assignment is more likely to end up with the same number in every run.

Either way:

This gives us something to work with and we can begin introducing other TyKinds one by one when we're ready to implement them and that's when we can work on resolving this instability.

👍 we can definitely work with this as a first step.

[jberthold]

👍 LGTM.
We can modify the debug content in a follow-up PR (and maybe also use a more idiomatic solution for it...)