Implement [LegacyLenientSetter] and test [LegacyLenientThis]
#209
Conversation
| brandCheck = ""; | ||
| const replaceable = utils.getExtAttr(this.idl.extAttrs, "Replaceable"); | ||
| const legacyLenientSetter = utils.getExtAttr(this.idl.extAttrs, "LegacyLenientSetter"); | ||
| const legacyLenientThis = utils.getExtAttr(this.idl.extAttrs, "LenientThis"); |
There was a problem hiding this comment.
As a bonus, can you enforce (via compile-time errors) the following:
An attribute with the [Replaceable] extended attribute must not also be declared with the [LegacyLenientSetter] or [PutForwards] extended attributes.
The [LegacyLenientSetter] extended attribute must take no arguments. It must not be used on anything other than a read only regular attribute.
An attribute with the [LegacyLenientSetter] extended attribute must not also be declared with the [PutForwards] or [Replaceable] extended attributes.
The [LegacyLenientThis] extended attribute must take no arguments. It must not be used on a static attribute.
The [Replaceable] extended attribute must take no arguments.
An attribute with the [Replaceable] extended attribute must not also be declared with the [LegacyLenientSetter] or [PutForwards] extended attributes.
The [Replaceable] extended attribute must not be used on an attribute that is not read only.
The [Replaceable] extended attribute must not be used on a static attribute.
(I've omitted the not-on-a-namespace checks since we don't do namespaces.)
Enforcing these would make it more obvious why we don't have tests for some of these cases.
If you would rather do these in a separate PR, perhaps including checks for all the other extended attributes we implement, that is fine too. Perhaps at that time we could even introduce a way of testing these errors.
There was a problem hiding this comment.
I intend to do that in its own PR.
|
Closing since this is from an organization and we don't accept PRs from organizations anymore. I'll reopen a new PR instead. |
This also fixes the bug where
[LegacyLenientThis]would still result in attempting to get the implementation value, even whenexports.is(esValue)wasfalse, which would result in aTypeErrorifesValuedid not have animplSymbolproperty.This will have merge conflicts with #206 and should probably be rebased on top of it, since it doesn’t make sense to have
[LegacyLenientThis]use the new naming scheme, but have[LegacyLenientSetter]using the old naming scheme.Part of #207