Closed Bug 943660 Opened 6 years ago Closed 6 years ago

Remove nsIMemoryReporter::name, because it's (a) unused and (b) a bad idea.

Categories

(Core :: XPCOM, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla28

People

(Reporter: njn, Assigned: njn)

References

Details

(Whiteboard: [qa-])

Attachments

(2 files)

nsIMemoryReporter::name is unused, AFAIK.  (It's conceivable that an add-on
might use it, though probably not.)

It's also a bad idea.  For one, each reporter is supposed to have a unique name
but there's nothing enforcing that.  More importantly, I've recently made
various changes that have moved us away from treating any kinds of memory
reporters or memory reports specially, which has been great.  Removing |name|
would be another step in that direction -- it would no longer be possible to
pluck out a single reporter from the full set and do something with it.
Attachment #8338904 - Flags: review?(continuation) → review+
Backed out because of use-after-free errors detected in Linux ASAN bc and Moth jobs:

https://hg.mozilla.org/integration/mozilla-inbound/rev/190eedf8577a
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=85486c4aa3d8
https://hg.mozilla.org/mozilla-central/rev/73fdb97e906b
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
In the first patch in this bug, I removed nsIMemoryReporter::name.  But I
missed some stuff.

- MemoryUniReporter::GetName() is no longer needed.

- MemoryUniReporter::mNameAndPath is now just mPath.

- MemoryMultiReporter::mName is no longer needed.  This means many
  explicit MemoryMultiReporter("foo") superclass constructor calls are no
  longer needed.
Attachment #8342130 - Flags: review?(continuation)
Attachment #8342130 - Flags: review?(continuation) → review+
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.