Join GitHub today
Improve Texp_record constructor representation #516
Accessing record information in the typedtree is not very practical, and the information about the type of kept fields (when using the
I propose to replace it by:
| Texp_record of record_label_definition array * Types.label_description array * Types.record_representation * expression option and record_label_definition = | Kept of Types.type_expr | Overridden of Longident.t loc * expression
This allows to easily access a particular field information (instead of searching for a field with the right field position).
The main motivation for this change is to provide the type information to translcore to propagate it to the lambda. In particular, the PR #336 would make use of it. I had a previous version that needed to do some unification after the type checking, but this version is a lot cleaner.
Notice that even if we lost the order of the fields in the parsetree, this does not affect the evaluation order. I added a test to verify that.
Notice that the evaluation order for record update depend on the number of fields updated:
Would anyone object if I changed the order to avoid this strangeness ?
Re-rebased to the current trunk.
Also use the type information to populate makeblock kinds in case of record update and add some test to check that this effectively allow unboxing in case of record update.
This test was failing first due to a bug introduced by #538 . This contain the fix for it.
referenced this pull request
Jul 7, 2016
I think it's a good change, but I did not review the patch itself.
Moreover, the comment in Typedtree is confusing since it leads to believe that only overridden fields are listed. Perhaps just adding a sentence about the fact that all fields of the record type are listed in the arrays would help.
The order I suggested (
Regarding (inline or not) record for the arguments: if you think this is a good idea, why not doing it in this PR? Typedtree is processed by external tools (reading .cmt files) so we should indeed aim at user-friendliness and stability (i.e. not change again the definition post 4.04).