Introduce IdlInterface#should_have_interface_object() method #23104
Conversation
|
Closing/reopening since TaskCluster didn't run here. |
shvaikalesh
force-pushed
the
should-have-interface-object
branch
from
bc94bef
to
9865895
Compare
|
@foolip Would you please take a look? With this change, a few
|
resources/idlharness.js
Outdated
| @@ -2596,6 +2603,12 @@ IdlInterface.prototype.test_member_iterable = function(member) | |||
| { | |||
| subsetTestByKey(this.name, test, function() | |||
| { | |||
| if (!this.should_have_interface_object()) { | |||
| return; | |||
There was a problem hiding this comment.
Is this early return hit in any test? It looks a bit suspect to create and pass these tests without testing anything, and that we'd need to especially care about this.should_have_interface_object() for testing iterator<T> but not async iterable, for example.
In other words, does anything bad happen if these additions are not made, or is there possible Web IDL where we'd assert the wrong this without these changes, even if no spec currently does that?
There was a problem hiding this comment.
No, it doesn't.
I've added this check & assert because a) test_member_stringifier() has it and b) WebIDL spec does not forbid iterable<> on interfaces with [LegacyNoInterfaceObject] extended attribute or callback interfaces.
However, I didn't find such iterable<> occurrence among WebKit's *.idl files (there is stringifier with [NoInterfaceObject] though), and both [LegacyNoInterfaceObject] and callback interfaces are legacy, so we are safe to remove it.
shvaikalesh
force-pushed
the
should-have-interface-object
branch
from
8f80e0a
to
2455ba2
Compare
Resolves #18827.