Move infallibility annotations into WebIDL

RESOLVED FIXED in mozilla16

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

(Blocks: 1 bug)

unspecified
mozilla16
x86
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

The current setup doesn't really scale very well, now that I've tried to convert CSSStyleDeclaration and the webgl context.
Assignee: nobody → bzbarsky
Created attachment 626337 [details] [diff] [review]
Move infallibility annotations into webidl.   this new setup, there are three new extended attributes: Infallible,
Comment on attachment 626337 [details] [diff] [review]
Move infallibility annotations into webidl.   this new setup, there are three new extended attributes: Infallible,

Peter, what do you think?  Both about the overall setup and the particular names I picked?

In some ways it would be nice to have a syntax that we could put after the attribute to avoid changing the line with the per-spec extended attributes, but I don't really want to hack up our parser if I don't have to....

I left the old mechanism in for now, but I can remove it if we think this works fine.

I would also be ok with nixing the worker/mainthread stuff and either requiring that things be flagged as infallible only if they're infallible on both workers and mainthread or that people who want to specify that sort of thing need to do so via the conf file...  But I think this setup is actually pretty simple.
Attachment #626337 - Flags: feedback?(peterv)
Whiteboard: [need feedback]
Attachment #626337 - Flags: review?(peterv)
Comment on attachment 626337 [details] [diff] [review]
Move infallibility annotations into webidl.   this new setup, there are three new extended attributes: Infallible,

Review of attachment 626337 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/bindings/Configuration.py
@@ +179,5 @@
>      def getExtendedAttributes(self, member, getter=False, setter=False):
>          name = member.identifier.name
>          if member.isMethod():
> +            attrs = self.extendedAttributes['all'].get(name, [])
> +            # Constructors seem to not have useful extended attr dicts?

What's this about? If that's why we have the |try| below I'd rather fix constructors. Aren't constructors IDLMethods?

@@ +188,5 @@
> +                if (infallible is not None and
> +                    (infallible is True or
> +                     ('Workers' in infallible and self.workers) or
> +                     ('MainThread' in infallible and not self.workers))):
> +                    attrs.append("infallible")

Do we want to throw for other values?

@@ +207,5 @@
> +        if (infallible is not None and
> +            (infallible is True or
> +             ('Workers' in infallible and self.workers) or
> +             ('MainThread' in infallible and not self.workers))):
> +            attrs.append("infallible")

Same here?
Attachment #626337 - Flags: review?(peterv)
Attachment #626337 - Flags: review+
Attachment #626337 - Flags: feedback?(peterv)
Attachment #626337 - Flags: feedback+
> If that's why we have the |try| below I'd rather fix constructors. Aren't constructors
> IDLMethods?

That's what it's about, yes.  Constructors are IDLMethods, but IDLInterfaceMember only sets up self._extendedAttrDict when addExtendedAttributes is called, and it's not called for constructors.

I'll just move that to IDLInterfaceMember.__init__.

> Do we want to throw for other values?

I can do that, yes.  Both places.
https://hg.mozilla.org/integration/mozilla-inbound/rev/ddfa6d5ad10a
Flags: in-testsuite?
Whiteboard: [need feedback]
Target Milestone: --- → mozilla16
Blocks: 749101
https://hg.mozilla.org/mozilla-central/rev/ddfa6d5ad10a
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Depends on: 778150
You need to log in before you can comment on or make changes to this bug.