[Webkit-unassigned] [Bug 176707] WSL IntLiteralType should become int32 if unified with a type variable

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=176707

--- Comment #1 from Filip Pizlo <fpizlo at apple.com> ---
An even easier approach is to teach UnificationContext that during verification, it should ask all literals to select a more specific type.  They don't have to do it if they don't want to.

This has to be done in two phases.  First all of the literals that were involved in unification have to be given an opportunity to observe that they are unified with a literal or type variable.  If they are, then they can sign up to be part of a pre-verification pass.

Once all literals have been given a chance to sign up, then we run the pre-verification pass, where they all try to unify themselves with a more specific type of their choosing.  This could fail, if two literals are involved in a unifying call:

void foo<T>(T, T);

foo(0, 0.);

We'll almost certainly want 0. to be a floatLiteralType that can unify with a variety of different types.  Maybe we want 0u to behave like that also.  So, what could happen here is that both intLiteralType and floatLiteralType observe that they are unified with T, and then they will both want to select their more specific types.  At this point, unless we do a two-phase approach, we could have undecidability: depending on whether intLiteralType or floatLiteralType is picked first, that one could determine the type that T becomes.  This means that the program will either type check and use T=double (if floatLiteralType runs first), or it will not type check because intLiteralType ran first, unified with int32, and then floatLiteralType's pre-verification would say "oh, OK, I'm unified with something that isn't a floatLiteralType or TypeVariable so I have nothing to do". Then during actual verification, floatLiteralType would observe that it got unified with int32, which is wrong.

The two-phase approach ensures that both intLiteralType and floatLiteralType sign up for unifying, and then it's guaranteed that they will detect the type error no matter what order they run in.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170914/a1e5cbbd/attachment.html>