Remove backend for lazy #6960
Remove backend for lazy #6960
Conversation
| @@ -191,7 +191,7 @@ let rec classify_expression : Typedtree.expression -> sd = | |||
| | Texp_ident _ | Texp_for _ | Texp_constant _ | Texp_new _ | Texp_instvar _ | |||
| | Texp_tuple _ | Texp_array _ | Texp_construct _ | Texp_variant _ | |||
| | Texp_record _ | Texp_setfield _ | Texp_while _ | Texp_setinstvar _ | |||
| | Texp_pack _ | Texp_object _ | Texp_function _ | Texp_lazy _ | |||
There was a problem hiding this comment.
You can't remove an item or the entire runtime representation is reindexed and the editor extension will crash.
Instead you can give it a unit payload and add a comment that it is unused.
There was a problem hiding this comment.
I am wondering if we should rename the unused constructors to something like Texp_unused_lazy.
There was a problem hiding this comment.
You can't remove an item or the entire runtime representation is reindexed and the editor extension will crash.
Instead you can give it a unit payload and add a comment that it is unused.
Could you explain how removing something from runtime related to the editor extension? I asked the same question in another PR, feel free to answer in a single place.
There was a problem hiding this comment.
There was a problem hiding this comment.
You can't remove an item or the entire runtime representation is reindexed and the editor extension will crash.
Instead you can give it a unit payload and add a comment that it is unused.Could you explain how removing something from runtime related to the editor extension? I asked the same question in another PR, feel free to answer in a single place.
The editor extension and the compiler operates on the same generated compiler artifacts. If we change the representation in these artifacts (which happens if we change the types enough) then things stop working.
In the future we'll have tools bound to a specific ReScript version so this isn't a problem. But right now that's not how it works, so we need to take that into account.
There was a problem hiding this comment.
The editor extension and the compiler operates on the same generated compiler artifacts.
The ones we have in printsmth files? So we can change the payload, but the variant should stay, so the print logic stays the same, is it correct?
| Texp_lazy (e) ->
line i ppf "Texp_lazy";
expression i ppf e;
Is it safe to add new items to the variant?
There was a problem hiding this comment.
To the payload, or add a new variant case at the end?
ParseTree is still there to be removed