Bug 6191 – RefPtr/PassRefPtr have a leak issue, operator== issues

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Misc.

[Darin Adler]

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)

[Darin Adler]

Marking P1 because of the potential leak.

[Darin Adler]

Created attachment 5212 [details]
patch that fixes the issues described in the bug

[Darin Adler]

*** Bug 6165 has been marked as a duplicate of this bug. ***

[Maciej Stachowiak]

Why this part: "Remove non-template constructor that takes RefPtr [from PassRefPtr]."

Other than that, all changes look great to me.

[Maciej Stachowiak]

r=me assuming you add a good explanation of why the PassRefPtr constructor that takes RefPtr was 
removed.

[Darin Adler]

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.

[Darin Adler]

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.