Closed Bug 1495031 Opened Last year Closed Last year

Eliminate ambiguous ctor for nsMaybeWeakPtr


(Toolkit :: Places, enhancement)

Not set



Tracking Status
firefox64 --- fixed


(Reporter: mccr8, Assigned: mccr8)




(1 file)

In bug 1494765, I'm adding some ctors to nsCOMPtr to allow automatic conversion from nsCOMPtr<A> to nsCOMPtr<B> when A is a subclass of B. This causes an error related to ambiguous constructors for the nsMaybeWeakPtr class.

The three ctors are:
  MOZ_IMPLICIT nsMaybeWeakPtr(nsISupports* aRef);
  MOZ_IMPLICIT nsMaybeWeakPtr(const nsCOMPtr<nsIWeakReference>& aRef);
  MOZ_IMPLICIT nsMaybeWeakPtr(const nsCOMPtr<T>& aRef);

The ambiguous call site is:
  if (!MaybeWeakArray::AppendElement(ref)) {
where ref has type nsCOMPtr<nsISupports>

It says the ambiguity is at
  new (static_cast<void*>(aE)) E(std::forward<A>(aArg));
inside elem_traits::Construct().

I'm not sure why this is ambiguous here, given that an nsISupports nsCOMPtr can't be converted to the second or third case, but it seems like there are only two ctors we really need: one for nsIWeakReference, when we want a weak ref, and one for T* when we want a strong ref.
When bug 1494765 adds support for conversion between nsCOMPtr<>s to
related types, code using nsMaybeWeakPtr fails to compile due to
ambiguous constructors. I'm not sure exactly why this is, but it seems
like we only really need to support two ctors: T* and
nsCOMPtr<nsIWeakReference>, for the cases of a strong and weak
reference, respectively.

The operator= overloads are needed for the branches in
Comment on attachment 9013014 [details]
Bug 1495031 - Eliminate ambiguous ctor for nsMaybeWeakPtr

Marco Bonardo [::mak] has approved the revision.
Attachment #9013014 - Flags: review+
Pushed by
Eliminate ambiguous ctor for nsMaybeWeakPtr r=mak
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in before you can comment on or make changes to this bug.