Closed Bug 1323042 Opened 3 years ago Closed 3 years ago

forbid MOZ_COUNT_{CTOR,DTOR} for nsISupports classes


(Core :: XPCOM, defect)

Not set



Tracking Status
firefox53 --- fixed


(Reporter: froydnj, Assigned: froydnj)


(Blocks 1 open bug)



(1 file)

No description provided.
r+'ing Andrew's patch from bug 1307961, minus the nsTraceRefcnt bits.
Attachment #8818075 - Flags: review+
Blocks: 1307961
Pushed by
forbid MOZ_COUNT_{CTOR,DTOR} for nsISupports classes; r=froydnj
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Depends on: 1323406
I'm having trouble to understand this. Sure, if the backend used the same stuff as refcnt logging, that could be annoying, but don't we want to be able to have the macros to ensure stuff gets deleted - especially in cases where refcnt handling is unusual.
Am I missing something?
Flags: needinfo?(continuation)
(In reply to Olli Pettay [:smaug] (r- if the bug doesn't explain what the change(s) are about.) from comment #4)
> Am I missing something?

The idea here was that people were adding these MOZ_COUNT_CTORs when they didn't need to, because they didn't realize that refcounted classes already did it for them. It is just nicer to not have the noisiness of this code that isn't needed, and it also adds a little more spamminess to the leaks when they do happen. If there's a particular case where you really want both (and I do understand why you might want it sometimes), we could add a variant of the CTOR/DTOR macro that doesn't have the check.
Flags: needinfo?(continuation)
You need to log in before you can comment on or make changes to this bug.