Closed Bug 1390036 Opened 7 years ago Closed 7 years ago

Remove nsXPIDLString

Categories

(Core :: XPCOM, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox57 --- fixed

People

(Reporter: n.nethercote, Assigned: n.nethercote)

References

Details

Attachments

(3 files, 3 obsolete files)

This is about removing nsXPIDLString. nsXPIDLCString will be removed in a different bug.
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: nobody → n.nethercote
Status: NEW → ASSIGNED
This requires adding a new constructor for ns[C]String that creates an IsVoid string.
Attachment #8896870 - Flags: review?(erahm)
Attached patch (part 3) - Remove nsXPIDLString (obsolete) (deleted) — Splinter Review
Note that nsXPIDLCString still exists. I will remove that later.
Attachment #8896872 - Flags: review?(erahm)
I forgot to mark the constructor |explicit| in this patch.
Attachment #8896886 - Flags: review?(erahm)
Attachment #8896870 - Attachment is obsolete: true
Attachment #8896870 - Flags: review?(erahm)
Attached patch (part 3) - Remove nsXPIDLString (deleted) — Splinter Review
Attachment #8896887 - Flags: review?(erahm)
Attachment #8896872 - Attachment is obsolete: true
Attachment #8896872 - Flags: review?(erahm)
Attachment #8896869 - Flags: review?(erahm) → review+
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)
Attachment #8896887 - Flags: review?(erahm) → review+
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+
(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.
<none>
Attachment #8897246 - Flags: review?(dbaron)
Attachment #8896886 - Attachment is obsolete: true
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+
(Or, on the other hand, maybe this should be adjusting NullCString as well, so that we can also remove nsXPIDLCString?)
(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.
> 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`.
Component: String → XPCOM
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: