Closed
Bug 1390036
Opened 7 years ago
Closed 7 years ago
Remove nsXPIDLString
Categories
(Core :: XPCOM, enhancement)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
mozilla57
Tracking | Status | |
---|---|---|
firefox57 | --- | fixed |
People
(Reporter: n.nethercote, Assigned: n.nethercote)
References
Details
Attachments
(3 files, 3 obsolete files)
(deleted),
patch
|
erahm
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
erahm
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
This is about removing nsXPIDLString. nsXPIDLCString will be removed in a different bug.
Assignee | ||
Comment 1•7 years ago
|
||
CompareCacheHashEntry::mCrit[] is the only case where the nsXPIDLString-ness
was important. The patch adds an explicit SetIsVoid() call to that class's
constructor and changes some null checks to IsVoid() checks.
Attachment #8896869 -
Flags: review?(erahm)
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → n.nethercote
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•7 years ago
|
||
This requires adding a new constructor for ns[C]String that creates an IsVoid
string.
Attachment #8896870 -
Flags: review?(erahm)
Assignee | ||
Comment 3•7 years ago
|
||
Note that nsXPIDLCString still exists. I will remove that later.
Attachment #8896872 -
Flags: review?(erahm)
Assignee | ||
Comment 4•7 years ago
|
||
I forgot to mark the constructor |explicit| in this patch.
Attachment #8896886 -
Flags: review?(erahm)
Assignee | ||
Updated•7 years ago
|
Attachment #8896870 -
Attachment is obsolete: true
Attachment #8896870 -
Flags: review?(erahm)
Assignee | ||
Comment 5•7 years ago
|
||
Attachment #8896887 -
Flags: review?(erahm)
Assignee | ||
Updated•7 years ago
|
Attachment #8896872 -
Attachment is obsolete: true
Attachment #8896872 -
Flags: review?(erahm)
Updated•7 years ago
|
Attachment #8896869 -
Flags: review?(erahm) → review+
Comment 6•7 years ago
|
||
Comment on attachment 8896886 [details] [diff] [review]
(part 2) - Remove nsXPIDLString use from NullString()
Review of attachment 8896886 [details] [diff] [review]:
-----------------------------------------------------------------
David, do you have an opinion here?
::: xpcom/string/nsTString.h
@@ +33,5 @@
> : substring_type(ClassFlags::NULL_TERMINATED)
> {
> }
>
> + explicit nsTString_CharT(bool aIsVoid)
I think I'd prefer just making |NullString| a friend of |nsTString_CharT| so that it can call the protected |nsTString_CharT(char_type*, size_type, DataFlags, ClassFlags)| constructor directly.
Attachment #8896886 -
Flags: review?(erahm) → feedback?(dbaron)
Updated•7 years ago
|
Attachment #8896887 -
Flags: review?(erahm) → review+
Comment 7•7 years ago
|
||
Comment on attachment 8896886 [details] [diff] [review]
(part 2) - Remove nsXPIDLString use from NullString()
I think I prefer the approach of exposing a new constructor on nsTString, but I think I'd prefer:
(a) making that new constructor protected, and
(b) probably exposing DataFlags as the type rather than boolean
(randomly setting the feedback? flag to something...)
Attachment #8896886 -
Flags: feedback?(dbaron) → feedback+
Comment 8•7 years ago
|
||
(In reply to David Baron :dbaron: ⌚️UTC-7 from comment #7)
> Comment on attachment 8896886 [details] [diff] [review]
> (part 2) - Remove nsXPIDLString use from NullString()
>
> I think I prefer the approach of exposing a new constructor on nsTString,
> but I think I'd prefer:
> (a) making that new constructor protected, and
> (b) probably exposing DataFlags as the type rather than boolean
>
> (randomly setting the feedback? flag to something...)
This sounds good, my main concern was the ctor not being protected.
Assignee | ||
Updated•7 years ago
|
Attachment #8896886 -
Attachment is obsolete: true
Comment 10•7 years ago
|
||
Comment on attachment 8897246 [details] [diff] [review]
(part 2) - Remove nsXPIDLString use from NullString()
>+ friend const nsString& NullString();
Please put this line in an
#ifdef CharT_is_PRUnichar
>+ explicit nsTString_CharT(DataFlags aDataFlags)
>+ : substring_type(ClassFlags::NULL_TERMINATED)
>+ {
>+ mDataFlags |= aDataFlags;
Instead of putting the mDataFlags manipulation in the body, could you call the other constructor:
: substring_type(char_traits::sEmptyBuffer, 0,
aDataFlags, ClassFlags::NULL_TERMINATED)
since this might, in the future, help with assertions that happen in that constructor?
r=dbaron with that
Attachment #8897246 -
Flags: review?(dbaron) → review+
Comment 11•7 years ago
|
||
(Or, on the other hand, maybe this should be adjusting NullCString as well, so that we can also remove nsXPIDLCString?)
Comment 12•7 years ago
|
||
(In reply to David Baron :dbaron: ⌚️UTC-7 from comment #10)
> Comment on attachment 8897246 [details] [diff] [review]
> (part 2) - Remove nsXPIDLString use from NullString()
>
> >+ friend const nsString& NullString();
>
> Please put this line in an
> #ifdef CharT_is_PRUnichar
I guess given (a) comment 0 and (b) that there's a NullCString function, it's probably best to add a macro for the name of the NullTString function to the "template" defines, and use that.
Assignee | ||
Comment 13•7 years ago
|
||
> Instead of putting the mDataFlags manipulation in the body, could you call
> the other constructor:
> : substring_type(char_traits::sEmptyBuffer, 0,
> aDataFlags, ClassFlags::NULL_TERMINATED)
> since this might, in the future, help with assertions that happen in that
> constructor?
Sure, though I will do `aDataFlags | DataFlags::TERMINATED` instead of just `aDataFlags`.
Assignee | ||
Comment 14•7 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/bd7a1aa5db733489256e531e4e6c8bac9b4aae98
Bug 1390036 (part 1) - Remove most remaining uses of nsXPIDLString. r=erahm.
https://hg.mozilla.org/integration/mozilla-inbound/rev/5e6de75921f1a41b02fbd2358edf3b23457105c9
Bug 1390036 (part 2) - Remove nsXPIDLString use from NullString(). r=dbaron.
https://hg.mozilla.org/integration/mozilla-inbound/rev/30b4593d421308ef2ba9d608732cfcf707c77b55
Bug 1390036 (part 3) - Remove nsXPIDLString. r=erahm.
Comment 15•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/bd7a1aa5db73
https://hg.mozilla.org/mozilla-central/rev/5e6de75921f1
https://hg.mozilla.org/mozilla-central/rev/30b4593d4213
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Updated•4 years ago
|
Component: String → XPCOM
You need to log in
before you can comment on or make changes to this bug.
Description
•