Record definition spread issues

[zth]

This does 2 things:

1. Fixes an issue where the fields being optional wasn't propagated through the new record type spread functionality. Before this, any optional field from a record that was then spread onto another record would no longer be optional.
2. Adds a commented out test for a case where the parser breaks as we're spreading a single type only, with no additional fields, as in copying the record to a new identical record. I think that's supposed to work?

[cristianoc]

2. Adds a commented out test for a case where the parser breaks as we're spreading a single type only, with no additional fields, as in copying the record to a new identical record. I think that's supposed to work?

Indeed. Forgot about that. The DotDotDot.res file already had a few examples not using the new syntax (but using \"..." ) because of that.

[cristianoc]

From reviewing the code some reflections:

• The fields from the record being spread are not type checked again, but their type is simply used as-is. (That might explain why the seemingly needed code to add option to the type has no effect).
• Another possibility is to extract the untyped parse tree for those fields and type check again. Though doing that would preclude the possibility of, in future, know what parts are coming from a spread and what parts are not. It might be useful, or it might not, to be seen.

Now that all the new features exist in isolation, there are a bunch of questions to answer:

• Are there unboxed records (perhaps with exactly 1 field if I remember)
• If they exist, can one spread it?
• Does it become boxed if it's not declared unboxed?
• If it's boxed, can one make one unboxed out of it?

So it looks like the design is not finished here. We can try to answer some of these questions and iterate some more see what comes out of it.

[cristianoc]

The question about unboxed apply to type coercion too.
Are we simply allow to coerce a boxed to an unboxed record and the other way round silently? That would not be safe.
What about @as(...)? Are we taking that into account correctly? Both in terms of spread and of type coercions.

Most of these questions can be answered by writing a few little tests.

[cristianoc]

I think that's is, if strictly speaking about the issue observed.
Notice there are a bunch of related questions in the issue, but this can be merged as-is (after updating the change log).

[zth]

@cristianoc check again, good to merge?