Cannot hide one WebIDL overload behind a pref

NEW
Unassigned

Status

()

Core
DOM
5 years ago
5 years ago

People

(Reporter: Ehsan, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 769780 [details] [diff] [review]
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?
(Reporter)

Updated

5 years ago
Blocks: 889016
(Reporter)

Updated

5 years ago
Blocks: 580070
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....
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.
(Reporter)

Comment 3

5 years ago
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?
(Reporter)

Comment 4

5 years ago
I took a different approach in bug 889016.  Feel free to resolve this as INVALID if it's not useful.
No longer blocks: 889016
You need to log in before you can comment on or make changes to this bug.