889014 - Cannot hide one WebIDL overload behind a pref

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[(no longer active)]

Attachment: Test patch

See the attached patch, which tries to hide one overload of the AudioContext.createBuffer function behind a pref.  This is what I get when I build this:

 0:23.93   File "/Users/ehsanakhgari/moz/mozilla-central/config/pythonpath.py", line 56, in <module>
 0:23.93     main(sys.argv[1:])
 0:23.93   File "/Users/ehsanakhgari/moz/mozilla-central/config/pythonpath.py", line 48, in main
 0:23.94     execfile(script, frozenglobals)
 0:23.94   File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/GlobalGen.py", line 78, in <module>
 0:23.94     main()
 0:23.94   File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/GlobalGen.py", line 56, in main
 0:23.94     parserResults = parser.finish()
 0:23.94   File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 4645, in finish
 0:23.94     production.finish(self.globalScope())
 0:23.94   File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 629, in finish
 0:23.94     member.resolve(self)
 0:23.94   File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 2917, in resolve
 0:23.94     IDLObjectWithIdentifier.resolve(self, parentScope)
 0:23.94   File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 368, in resolve
 0:23.94     self.identifier.resolve(parentScope, self)
 0:23.94   File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 341, in resolve
 0:23.94     scope.ensureUnique(self, object)
 0:23.94   File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 250, in ensureUnique
 0:23.94     object)
 0:23.94   File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 552, in resolveIdentifierConflict
 0:23.94     originalObject, newObject)
 0:23.94   File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 270, in resolveIdentifierConflict
 0:23.94     return originalObject.addOverload(newObject)
 0:23.94   File "/Users/ehsanakhgari/moz/mozilla-central/dom/bindings/parser/WebIDL.py", line 2929, in addOverload
 0:23.94     [self.location, method.location])
 0:23.94 WebIDL.WebIDLError: error: Extended attributes differ on different overloads of <unresolved scope>::createBuffer, AudioContext.webidl line 25:4
 0:23.94     AudioBuffer createBuffer(unsigned long numberOfChannels, unsigned long length, float sampleRate);

Does anybody know how to deal with this problem?

Comment 1

[Boris Zbarsky [:bzbarsky]]

Yep.  This is not supported given how overloads are represented right now.  They're just combined into a single IDL method with a bunch of signatures; a signature is a return type and some arguments.  There's no other per-signature information stored.

Supporting it is pretty nontrivial in general, given how complex overload resolution is already.  We'd basically need to output two entirely different instances of overload resolution and call them based on a pref or something...

Maybe we can do something simpler specifically for the case when the prefable argument at the distinguishing index is an interface type; it should be simple to tweak the generated code to handle that if the data model were to preserve information about which signatures are prefable and which are not....

Comment 2

[Boris Zbarsky [:bzbarsky]]

But the simpler alternative in this particular case is probably to just expose the signature unconditionally and then in the ArrayBuffer overload either throw if the pref is not set or convert the arraybuffer to an integer and call the other overload if you want to simulate the behavior of that overload really really not existing.  Either one is doable, because dom::ArrayBuffer gives you access to the underlying JSObject.

Comment 3

[(no longer active)]

We don't need to simulate anything since the semantics of these two functions are very different in fact.  What would be the right exception to throw in this case?

Comment 4

[(no longer active)]

I took a different approach in bug 889016.  Feel free to resolve this as INVALID if it's not useful.

Comment 5

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.