https://piazza.com/class/lcquw2vc2cs73i/post/195
I'll consider this a bug. Any existing info fields should have been preserved, since the source language contains an info field, and the info field is only a partial spec (technically, it's meant to be understood as a row-polymorphic record). But the reference compiler discards the additional entries.
However, it's reasonable for uncover-locals to throw away an existing locals field. The specification for uncover-locals tells us that it introduces that field, officially, to the compiler, and what the field contains. uncover-locals must be responsible for that field, and it cannot trust any values that were in there before, or a bug caused by a bad locals field would risk being blamed on uncover-locals unjustly. The same reason applies to any pass that introduces an info field.
https://piazza.com/class/lcquw2vc2cs73i/post/195 I'll consider this a bug. Any existing info fields should have been preserved, since the source language contains an info field, and the info field is only a partial spec (technically, it's meant to be understood as a row-polymorphic record). But the reference compiler discards the additional entries.
However, it's reasonable for
uncover-locals
to throw away an existinglocals
field. The specification foruncover-locals
tells us that it introduces that field, officially, to the compiler, and what the field contains.uncover-locals
must be responsible for that field, and it cannot trust any values that were in there before, or a bug caused by a badlocals
field would risk being blamed onuncover-locals
unjustly. The same reason applies to any pass that introduces an info field.