Add constructors for types

[biboudis]

Add all the constructors for Types here library/src/scala/tasty/reflect/TypeOrBoundsOps.scala

For testing we can create a TypeMap. Pass types deconstructing and constructing again and check the identity (note: check tests for TreeMap from library/src/scala/tasty/reflect/TreeUtils.scala, the test is tests/run/tasty-tree-map adapted from the corresponding one from the compiler)

[liufengyun]

@nicolasstucki : you forget to make a PR? b379dd7

[nicolasstucki]

@biboudis wants to do it

[fhackett]

Hi, I'm trying to get started as a contributor and @nicolasstucki suggested I try working on this issue (see mention above). My focus is to enable macro developers to work with more complex local expressions than is currently possible at the Tasty level. See #7626 for my motivating example.

Since I'm new to this I'll try to document my progress in case anyone has comments / criticism / etc.

For starters, I'm aiming to get some tests written. I see the note that working based on TreeMap could be useful, but I also notice that that uses *.copy(original)(...) rather than typical constructor calls. Identity tests make sense for transformations, but for construction wouldn't it make more sense to test that we can splice the results of these constructors into generated code?

[nicolasstucki]

Indeed, splicing the result seems to be the way to do it.

[fhackett]

Progress update: I've caught some of the low-hanging fruit like ConstantType, AndType, OrType and TypeBounds. My changes are stored here: https://github.com/fhackett/dotty/tree/fhackett-work-on-6280

When trying to work with more interesting types like TypeLambda however I'm getting confused. The TypeLambda from TypesOrBounds seems to only refer to generic lambdas, while there is a different LambdaTypeTree that is used for actual type lambdas.

Can anyone clarify what the relationship is between Type and TypeTree? It's not clear to me from source code or usage right now.

[fhackett]

@olhotak helped me understand the above question irl. I was also enlightened as to the value of the Dotty videos vs reading textual docs as I was originally doing. Thanks!

For today's update, I managed to get almost all of the Tasty type constructors that make sense implemented and tested.

Aside: turns out my implementation for TypeLambda constructor was actually correct, there was just a Dotty implementation quirk that means that an immediately-applied HKTypeLambda (with AppliedType, as opposed to AppliedTypeTree) seems to never exist "in nature" due to early simplification, so making one in Tasty causes many strange, broken results. I "fixed" my tests to use an AppliedTypeTree materialized via quotes instead.

Assuming I don't think of something new to do over night (and no-one comments anything big in that time), PR coming soon.

[nicolasstucki]

A TypeTree represents user syntax for a Type. This implies that every TypeTree has a Type and a position in source. But the full structure of a Type does not necessarily map back to a TypeTree.

val a = List(2)
val b: List[Int] = List(2)

Both a and b will have the type List[Int] but only b will have the TypeTree representing the type in the source.

[fhackett]

Having taken care of most of the simpler types (references aside), MethodType and PolyType remain. MethodType already has a constructor whereas PolyType does not.

I've experimented a bit and cannot find any sane way of checking these types against something else with =:= like in the PR above - turns out accessing the type of a method is prevented as such types are not considered stable.

That said, I have a plan to make these type constructors usable in practice (so, testable): implementing local method synthesis. The idea is to combine tpd.polyDefDef, which uses an existing symbol and its (method) type to generate a synthetic DefDef tree, with a synthetic symbol (given an appropriate parent derived from the Context owner) and a synthetic type.

With that feature, we can effectively test constructed MethodType and PolyType by using them to synthesize different kinds of local method. Bonus points for this being the feature that lead to me taking on this issue in the first place.

If no serious problems with this are exposed, I'll try putting together a second PR for this sometime next week.