I actually couldn't figure out a way to trigger this assertion with the
current string code without doing invalid casts, but there are things we
may want to add to the string code in the future that might risk hitting
this (e.g., move constructors, promoting various rebind methods to
nsA[C]String), so I think it's worth asserting.
MozReview-Commit-ID: 4R0dYuTfrFW
--HG--
extra : transplant_source : %B6%87I%0E%7F%21%CC2%19%CD%A7%E6TRA%9D%AEO%90%D7
This is needed for patch 4.
MozReview-Commit-ID: 4BFlTtQdtoN
--HG--
extra : transplant_source : %7C%F7%FDN%E5%7Df%0C%7D%10%EF%C0%25%B9%D6%18%1E%93%BE%A0
This is needed for patch 4.
MozReview-Commit-ID: 5ikQFIL9O0i
--HG--
extra : transplant_source : %88%80%E3%04%11%7E%7F%A4%7E%15%1B%1A%84%E2%13%3E%F6%E8%2A%1C
I believe this should fix some incorrect clearing of F_CLASS_FIXED.
MozReview-Commit-ID: 4ga2NEM9M5Z
--HG--
extra : transplant_source : %ECF%CF%D0%F6%19%9F%24%86%EFR%CAVZ%ED%60%D5nU%D8
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
All the instances are converted as follows.
- nsSubstring --> nsAString
- nsCSubstring --> nsACString
--HG--
extra : rebase_source : cfd2238c52e3cb4d13e3bd5ddb80ba6584ab6d91
All the instances are converted as follows.
- nsAFlatString --> nsString
- nsAFlatCString --> nsCString
--HG--
extra : rebase_source : b37350642c58a85a08363df2e7c610873faa6e41
All the instances are converted as follows.
- nsASingleFragmentString --> nsAString
- nsASingleFragmentCString --> nsACString
--HG--
extra : rebase_source : e6a1ddc8938fecd9a735b15e872c054edf4c7910
We don't need the tiny helper function for single-character assignment,
and the multi-argument assign() method is the only thing that uses it,
which is also itself unused. So remove them both.
This annotates vsprintf-like functions with MOZ_FORMAT_PRINTF. This may
provide some minimal checking of such calls (the GCC docs say that it
checks for the string for "consistency"); but in any case shouldn't
hurt.
MozReview-Commit-ID: HgnAK1LiorE
--HG--
extra : rebase_source : 9c8d715d6560f89078c26ba3934e52a2b5778b6a
For people working on Rust code, compiling in debug mode (Cargo's "dev"
profile) is convenient: debug assertions are turned on, optimization is
turned off, and parallel compilation inside of rustc itself can be
used. These things make the build faster and the debugging experience
more pleasant.
To obtain that currently, one needs to --enable-debug at the Gecko
toplevel, which turns on debug assertions for the entire browser, which
makes things run unreasonably slowly. So it would be desirable to be
able to turn *off* debug mode for the entirety of the browser, but turn
on debug mode for the Rust code only.
Hence this added switch, --enable-rust-debug, which does what it
suggests and defaults to the value of --enable-debug. For our own
sanity and because we judge it a non-existent use case, we do not
support --enable-debug --disable-rust-debug.
This is the same optimization made for ThreadSafeAutoRefCnt in bug
1277709. However, nsStringBuffer uses a 32-bit reference count all the
time, so it can't easily use ThreadSafeAutoRefCnt.
MozReview-Commit-ID: LpB3xaYbaEE
--HG--
extra : transplant_source : %89%FA%02%402%B1%83%17%81%09%EEw%B0%85%A0%B2%8DK/%D6
This patch adds a series of fallible methods for the rust ns[C]String
bindings, as well as the `set_length` method, which is the same as the
`SetLength` method in C++. `set_length` is marked as unsafe.
The decision was made to make the fallible methods seperate from the
infallible methods, and to use seperate Rust->C++ bindings for each of
them, rather than only binding the fallible bindings, and unwrapping
them in rust-land. This is to try to match the C++ API as closely as
possible, and to ensure that the behavior matches.
MozReview-Commit-ID: FkSomkFUFGD
As of the previous patch, these are now unused and aren't really buying us much.
MozReview-Commit-ID: HGliIFAcBb7
--HG--
extra : rebase_source : f39105fcb15e1c7eccae5088b34352e849f1b2b6
This is the patch that all the others have been leading up to: by inheriting from nsTStringRepr, nsTLiteralString loses its destructor (previously suppplied by nsTSubstring).
I included an AsString() cast as an escape hatch for a few pieces of code that couldn't easily accommodate the new hierarchy, but I'm pretty pleased with how little it was necessary.
MozReview-Commit-ID: 2zGkaw1sMUp
--HG--
extra : rebase_source : 68bbdc893850e4b6073d6fc2f036e53853b8927e
This prevents the antipattern found in bug 1341513.
MozReview-Commit-ID: JhxgC7aQDUA
--HG--
extra : rebase_source : b1ff0d240df87b2cbb415183dc93acc8bde7960a
This requires some adjustment to Equals(). Previously, when you wrote:
fooString.Equals(barString + bazString)
you'd get a tuple for the operator+, which implicitly converts to nsTSubstring, which resolves into nsTSubstring::Equals(const nsTSubstring&).
Now that Equals has moved one level up:
nsTStringRepr::Equals(const nsTStringRepr&)
The compiler can't make the double-leap from nsTSubstringTuple -> nsTSubstring -> nsTStringRepr.
So I implemented this manually.
MozReview-Commit-ID: 5x8XhndOToJ
--HG--
extra : rebase_source : ab0ec1259af522ea47a237e01f69dd28e593eacd
In the next patch, tuples will work on nsTStringRepr rather than nsTSubstring, so the notions of TO_SUBSTRING and substring_type are not quite right.
MozReview-Commit-ID: LpUwmGQAWVO
--HG--
extra : rebase_source : 6142500a3d4218d74dda11736b94cf08d6f55335
All nsTStringRepr methods must be const, so the mutators remain on nsTSubstring.
I left a small number of const methods on nsTSubstring, e.g. Capacity(), the rationale being that you would only be interested in this method if you intend to mutate the string.
I considered splitting up the typedefs block and leaving behind the ones related to mutation (e.g. nsWritingIterator) but I think it makes for clearer documentation to have them all in one place.
MozReview-Commit-ID: 7dEaRgc8NLK
--HG--
extra : rebase_source : 01b387b7e5bf2f21d6af1afcccf6ec0d7e8a2ac7
I've named it after the similar ns(C)StringRepr in the rust bindings code.
This is just the minimal definition of the structure. Bulk move of methods coming in next patch.
MozReview-Commit-ID: 4aQrpIWRTm7
--HG--
extra : rebase_source : e89d6fbacbaf6e26028e13848ce2877c8f245ba6
Cleanup in preparation for upcoming patches:
- By using an accessor method, nsTPromiseFlatString no longer needs to be a friend.
- The explicit uint32_t constructors are unused.
- The abstract_string_type typedef is unused (and will be potentially confusing in the next patch, so removing).
- The three-param ctor for nsTSubstring no longer needs to be public "for convenience".
- friend class nsTObsoleteAStringThunk_CharT no longer exists.
MozReview-Commit-ID: 4ibJLNzn13k
--HG--
extra : rebase_source : d5a947f398a6dfc801f644f437bae9125424d4d0
As of the previous patch, these are now unused and aren't really buying us much.
MozReview-Commit-ID: HGliIFAcBb7
--HG--
extra : rebase_source : f39105fcb15e1c7eccae5088b34352e849f1b2b6
This is the patch that all the others have been leading up to: by inheriting from nsTStringRepr, nsTLiteralString loses its destructor (previously suppplied by nsTSubstring).
I included an AsString() cast as an escape hatch for a few pieces of code that couldn't easily accommodate the new hierarchy, but I'm pretty pleased with how little it was necessary.
MozReview-Commit-ID: 2zGkaw1sMUp
--HG--
extra : rebase_source : 68bbdc893850e4b6073d6fc2f036e53853b8927e
This prevents the antipattern found in bug 1341513.
MozReview-Commit-ID: JhxgC7aQDUA
--HG--
extra : rebase_source : b1ff0d240df87b2cbb415183dc93acc8bde7960a
This requires some adjustment to Equals(). Previously, when you wrote:
fooString.Equals(barString + bazString)
you'd get a tuple for the operator+, which implicitly converts to nsTSubstring, which resolves into nsTSubstring::Equals(const nsTSubstring&).
Now that Equals has moved one level up:
nsTStringRepr::Equals(const nsTStringRepr&)
The compiler can't make the double-leap from nsTSubstringTuple -> nsTSubstring -> nsTStringRepr.
So I implemented this manually.
MozReview-Commit-ID: 5x8XhndOToJ
--HG--
extra : rebase_source : ab0ec1259af522ea47a237e01f69dd28e593eacd
In the next patch, tuples will work on nsTStringRepr rather than nsTSubstring, so the notions of TO_SUBSTRING and substring_type are not quite right.
MozReview-Commit-ID: LpUwmGQAWVO
--HG--
extra : rebase_source : 6142500a3d4218d74dda11736b94cf08d6f55335
All nsTStringRepr methods must be const, so the mutators remain on nsTSubstring.
I left a small number of const methods on nsTSubstring, e.g. Capacity(), the rationale being that you would only be interested in this method if you intend to mutate the string.
I considered splitting up the typedefs block and leaving behind the ones related to mutation (e.g. nsWritingIterator) but I think it makes for clearer documentation to have them all in one place.
MozReview-Commit-ID: 7dEaRgc8NLK
--HG--
extra : rebase_source : 01b387b7e5bf2f21d6af1afcccf6ec0d7e8a2ac7
I've named it after the similar ns(C)StringRepr in the rust bindings code.
This is just the minimal definition of the structure. Bulk move of methods coming in next patch.
MozReview-Commit-ID: 4aQrpIWRTm7
--HG--
extra : rebase_source : e89d6fbacbaf6e26028e13848ce2877c8f245ba6
Cleanup in preparation for upcoming patches:
- By using an accessor method, nsTPromiseFlatString no longer needs to be a friend.
- The explicit uint32_t constructors are unused.
- The abstract_string_type typedef is unused (and will be potentially confusing in the next patch, so removing).
- The three-param ctor for nsTSubstring no longer needs to be public "for convenience".
- friend class nsTObsoleteAStringThunk_CharT no longer exists.
MozReview-Commit-ID: 4ibJLNzn13k
--HG--
extra : rebase_source : d5a947f398a6dfc801f644f437bae9125424d4d0
This just-so-happened to work because nobody refers to the splitter directly by name.
The added gtest doesn't actually prove that this patch fixes anything, but I figured we could use a wide string for good measure.
MozReview-Commit-ID: 1ADy4X44HO1
Nothing uses these defines, so we should remove them lest anybody get
confused. I would have also removed kAutoDetect (who would want to do
this?!), but kAutoDetect is used in one place in the tree, and I didn't
want to hold up the deletion of these two items with trying to fix that
one place.
Iterators shouldn't have methods like write(); if you need to write to
an iterator, that logic should be handled by something outside of the
iterator...which also explains why we have a specialization of
nsCharTraits<nsWritingIterator<T>>. The HTML parser wants this for its
own reasons, so we have to make sure it continues to work.
This change is necessary so we can start using a pair of
iterators (current, end) and subtract them to figure out how far we have
left to go. The current code just uses size_forward and size_backward
for this purpose, and it's quite an unusual iterator that knows how far
it can go until it's done.
Asking for size_forward on an iterator that you haven't started reading
from is just asking for the length of the original string, so use that
instead.
