I have a patch that fixes these things: 1) adds a constructor that lets you mix PassRefPtr objects of compatible types 2) optimizes PassRefPtr::adopt so it doesn't first set m_ptr to 0 3) allows assignment of PassRefPtr objects from a RefPtr of any compatible type and vice versa 4) fixes a leak in the type conversion operator that converts a PassRefPtr to one of another compatible type 5) allows mixing compatible types in == and != for PassRefPtr and RefPtr 6) removes extraneous const in == and != operator implementations (which was probably harmless)
Marking P1 because of the potential leak.
Created attachment 5212 [details] patch that fixes the issues described in the bug
*** Bug 6165 has been marked as a duplicate of this bug. ***
Why this part: "Remove non-template constructor that takes RefPtr [from PassRefPtr]." Other than that, all changes look great to me.
r=me assuming you add a good explanation of why the PassRefPtr constructor that takes RefPtr was removed.
Here's the rationale: There's still a template constructor that takes a RefPtr in PassRefPtr that should cover any RefPtr. I believe there's no need for a non-template constructor specifically for a RefPtr to the same class as the PassRefPtr.
I'm not entirely clear in what situations it's helpful to have both a constructor and constructor template that overlap. I believe in the case of constructing a PassRefPtr from a RefPtr that the constructor template suffices by itself and we don't also need the non-template constructor.