Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

record inside union is not handled correctly in overload resolution algorithm #189

Closed
bzbarsky opened this issue Oct 17, 2016 · 1 comment

Comments

@bzbarsky
Copy link
Collaborator

Consider this idl:

void foo((Node or record<DOMString, Node>) arg);
void foo(DOMString arg);

and a call like so:

foo(null);

Which overload would be selected? If a dictionary were used instead of a record, the first overload would be selected. But with the current spec text for record, the second overload will be selected, as far as I can tell: https://heycam.github.io/webidl/#es-overloads step 11 substep 3 the last item doesn't include records, only dictionaries.

@jyasskin, @domenic, @tobie

@bzbarsky
Copy link
Collaborator Author

This is fallout from #180

tobie added a commit to tobie/webidl that referenced this issue Oct 17, 2016
Fix distinguishable algorithm. Closes whatwg#190.
Fix record handling in various algorithms. Closes whatwg#191, closes whatwg#189
tobie added a commit to tobie/webidl that referenced this issue Oct 17, 2016
Fix distinguishable algorithm. Closes whatwg#190.
Fix record handling in various algorithms. Closes whatwg#191, closes whatwg#189
tobie added a commit to tobie/webidl that referenced this issue Oct 17, 2016
Fix distinguishable algorithm. Closes whatwg#190.
Fix record handling in various algorithms. Closes whatwg#191, closes whatwg#189.
tobie added a commit that referenced this issue Oct 18, 2016
Fix distinguishable algorithm. Closes #190.
Fix record handling in various algorithms. Closes #191, closes #189.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant