811632 - Using a method which accepts a Web IDL callback type on a native object implemented in a namespace breaks the build

Status: RESOLVED INVALID

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

Description

[(no longer active)]

This patch <https://gist.github.com/4070688> triggers the following error:

AudioContext.cpp
In file included from /Users/ehsanakhgari/moz/mozilla-central/content/media/webaudio/AudioContext.cpp:7:
In file included from /Users/ehsanakhgari/moz/mozilla-central/content/media/webaudio/AudioContext.h:18:
../../../dist/include/mozilla/dom/AudioContextBinding.h:156:12: error: no matching function for call to 'Wrap'
    return Wrap(aCx, aScope, aObject, aObject, aTriedToWrap);
           ^~~~
/Users/ehsanakhgari/moz/mozilla-central/content/media/webaudio/AudioContext.cpp:60:10: note: in instantiation of function template specialization
      'mozilla::dom::mozAudioContextBinding::Wrap<mozilla::dom::AudioContext>' requested here
  return mozAudioContextBinding::Wrap(aCx, aScope, this, aTriedToWrap);
         ^
../../../dist/include/mozilla/dom/AudioContextBinding.h:151:3: note: candidate function not viable: no known conversion from 'mozilla::dom::AudioContext *' to
      'AudioContext *' for 3rd argument
  Wrap(JSContext* aCx, JSObject* aScope, AudioContext* aObject, nsWrapperCache* aCache, bool* aTriedToWrap);
  ^
../../../dist/include/mozilla/dom/AudioContextBinding.h:154:20: note: candidate function template not viable: requires 4 arguments, but 5 were provided
  inline JSObject* Wrap(JSContext* aCx, JSObject* aScope, T* aObject, bool* aTriedToWrap)
                   ^
1 error generated.


The issue is that in nsAudioContextBinding.h, AudioContext is forward declared outside of mozilla::dom, which means that later on before we see the declaration of AudioContext, we'll try to use the wrong class.

Comment 1

[(no longer active)]

This patch seems to fix things, but I'm not sure if it's the right thing to do (or if it's necessary): https://gist.github.com/4070760

Comment 2

[Boris Zbarsky [:bzbarsky]]

Yes, I think that patch is absolutely the right thing to do.  The fact that things compiled correctly the other way is pretty odd: how was the header being found before?

Comment 3

[(no longer active)]

(In reply to comment #2)
> Yes, I think that patch is absolutely the right thing to do.  The fact that
> things compiled correctly the other way is pretty odd: how was the header being
> found before?

Who knows?!  ;-)  So, can I just close this bug?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Assuming we land that patch, yes.