Raise blame error when trying to access fields in the sealed tail of a polymorphic record

[matthew-healy]

This updates SealedTail to store a HashSet of the identifiers which the tail contains. Then, when we hit a point where we'd otherwise raise a FieldMissing error, we check whether the field is in the sealed tail. If so, we instead raise a blame error.

This closes #952.

[vkleen]

👍 I was wondering whether it might be better to not duplicate the information which fields are contained in the tail. But I think, your solution is better; finding the contained fields from a RichTerm would be quite annoying. Even though the sealing code path might be rather hot if a statically typed function using polymorphic tails is used, constructing the HashSet hopefully isn't a big deal.

[matthew-healy]

@vkleen Yeah, iirc when I discussed this with @yannham last year we decided this was likely to be a reasonable compromise initially.

Though, to be honest, I was happier with this solution before it involved allocating a new String for every Ident in the tail. I can't really see any way to avoid doing that and still get O(1) containment checking, but maybe taking linear time to check if an element is in the tail would be okay since we only hit that codepath when we already know we're going to raise some sort of error... 🤔

If so, then we could just store a Vec<Ident>, which avoids the extra string allocations.

[vkleen]

Storing a Vec<Ident> actually sounds pretty reasonable. Generally, we don't care about the performance of the error path (within limits). Being able to avoid the String allocation should be worth that cost, I think.

[matthew-healy]

Alright, sounds good. Thanks!