Currently there are two separate sets of printing methods for Analyser.Type (anything other than Data.ip_index) and InternPool.Index respectively. They are largely the same but differ subtly in many ways, causing inconsisent behaviours across different LSP features.
For example, I am currently fixing the type resolution for builtin functions:
@addWithOverflow(1, 2).<cursor>
// @"0": (unknown type)
// @"1": u1
// len: usize = 2
@shlWithOverflow(1, 2).<cursor>
// @"0": (unknown value) !!
// @"1": u1
// len: usize = 2
For both @addWithOverflow and @shlWithOverflow, I call Type.createTupleType to generate the result Analyser.Type. However, for @addWithOverflow(1, 2) the .data field is an interned Data.ip_index, while for @shlWithOverflow(1, 2) it is a Data.tuple. The differences in printing logic between Analyser.Type and InternPool.Index result in @"0": (unknown type) vs @"0": (unknown value). There are many more inconsistencies for other types. While it is possible to fix the printing issues on an ad-hoc basis, having two duplicated sets of printing logic is not desirable, as evidenced by the many subtle bugs I have tracked down so far. Simply put, Analyser.Type is a leaky abstraction for printing currently.
Therefore, I suggest creating one single canonical data structure representing a fully reified type which will include all formatting methods for types.
Currently there are two separate sets of printing methods for
Analyser.Type(anything other thanData.ip_index) andInternPool.Indexrespectively. They are largely the same but differ subtly in many ways, causing inconsisent behaviours across different LSP features.For example, I am currently fixing the type resolution for builtin functions:
For both
@addWithOverflowand@shlWithOverflow, I callType.createTupleTypeto generate the resultAnalyser.Type. However, for@addWithOverflow(1, 2)the.datafield is an internedData.ip_index, while for@shlWithOverflow(1, 2)it is aData.tuple. The differences in printing logic betweenAnalyser.TypeandInternPool.Indexresult in@"0": (unknown type)vs@"0": (unknown value). There are many more inconsistencies for other types. While it is possible to fix the printing issues on an ad-hoc basis, having two duplicated sets of printing logic is not desirable, as evidenced by the many subtle bugs I have tracked down so far. Simply put,Analyser.Typeis a leaky abstraction for printing currently.Therefore, I suggest creating one single canonical data structure representing a fully reified type which will include all formatting methods for types.