Required by https://qwasm2.m-h.org.uk, which adds a custom `name`
attribute to objects it generates. It then gets some of these objects
out with getParameter, and expects the `name` attribute to be there.
Previously, a method with multiple sequence arguments would cause a
compile error, as the same variable name was redeclared when iterating
the sequence for each argument. This change disambiguates these
variable names.
This change fixes the IDLGenerators.cpp implementation of the “If
reflectedTarget's explicitly set attr-element is a descendant of any of
element's shadow-including ancestors” step from the “If a reflected IDL
attribute has the type T?, where T is either Element or an interface
that inherits from Element” case in the HTML spec at
http://whatwg.org/html/#reflecting-content-attributes-in-idl-attributes
This change updates the BindingsGenerator/IDLGenerators.cpp code to
handle reflected non-HTML::AttributeNames content-attribute names, and
to handle such names as-is — including names with dashes.
This change updates the bindings generator for the case defined at
https://html.spec.whatwg.org/#reflecting-content-attributes-in-idl-attributes:element;
that is, the case “If a reflected IDL attribute has the type T?, where T
is either Element or an interface that inherits from Element”.
The change “normalizes” the generator behavior for that case — such that
the generated code expects a getter with a name of the form used in
other cases; e.g., popover_target_element().
Otherwise, without this change, the generator expects a name of the form
get_popover_target_element() for that case.
1. Stop using GC::Root in member variables, since that usually creates
a realm leak.
2. Stop putting OrderedHashMap<FlyString, GC::Ptr> on the stack while
setting these up, since that won't protect the objects from GC.
Some WPT tests expect that if you go out of your way to
Object.getOwnPropertyDescriptor on an interface object and extract
the setter out of it, that they throw when called with no arguments.
When we originally implemented calc(), the result of a calculation was
guaranteed to be a single CSS type like a Length or Angle. However, CSS
Values 4 now allows more complex type arithmetic, which is represented
by the CSSNumericType class. Using that directly makes us more correct,
and allows us to remove a large amount of now ad-hoc code.
Unfortunately this is a large commit but the changes it makes are
interconnected enough that doing one at a time causes test
regressions.
In no particular order:
- Update our "determine the type of a calculation" code to match the
newest spec, which sets percent hints in a couple more cases. (One of
these we're skipping for now, I think it fails because of the FIXMEs
in CSSNumericType::matches_foo().)
- Make the generated math-function-parsing code aware of the difference
between arguments being the same type, and being "consistent" types,
for each function. Otherwise those extra percent hints would cause
them to fail validation incorrectly.
- Use the CSSNumericType as the type for the CalculationResult.
- Calculate and assign each math function's type in its constructor,
instead of calculating it repeatedly on-demand.
The `CalculationNode::resolved_type()` method is now entirely unused and
has been removed.
This reverts commit 76daba3069.
We're going to need separate types for the JS-exposed style values, so
it doesn't make sense for us to match their names with our internal
types.
When applied, corresponding interface object will not be exposed on the
global object, e.g. for the following IDL:
```
Exposed=(Window,Worker), LegacyNoInterfaceObject]
interface ANGLE_instanced_arrays {
};
```
executing `"ANGLE_instanced_arrays" in window` will return `false`.
When message encoding failed for some reason, we'd just swallow the
error without saying a word, and carry on without sending anything.
This led to some very confusing situations.
This way we could be sure that context object won't be deallocated
before any of the objects that belong to it.
Having a context pointer is also going to be used in upcoming changes
to generate an INVALID_OPERATION error if an object does not belong to
the context it's being used in.
