`char16_t` and `wchar_t` are functionally the same on Windows. But logging statements do not handle `char16_t` very well, resulting in the need to static cast to `wchar_t`. For more info, see [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1768758 | bug task ]]:
This diff introduces a Windows-specific function for getting strings as `wchar_t` and replaces previous workaround usages.
Differential Revision: https://phabricator.services.mozilla.com/D215869
Because the JS engine now increments the refcount itself, we can also simplify
the code a bit.
This patch removes `DOMString::RelinquishBufferOwnership` and `nsTSubstring::ForgetSharedBuffer`
because it's hard to make that optimization work with the new system.
Differential Revision: https://phabricator.services.mozilla.com/D213970
Because the JS engine now increments the refcount itself, we can also simplify
the code a bit.
This patch removes `DOMString::RelinquishBufferOwnership` and `nsTSubstring::ForgetSharedBuffer`
because it's hard to make that optimization work with the new system.
Differential Revision: https://phabricator.services.mozilla.com/D213970
Inline Create() and Realloc() so that we don't get negative leaks, since
were that code end up in mozglue, it wouldn't have access to the logging
machinery.
Differential Revision: https://phabricator.services.mozilla.com/D209663
Previously if the we got a subsystem id like 87731043 we would
fail to parse it because it's too big to fit in int32_t.
This adds a ToUnsignedInteger helper that lets us parse
the large subsystem ids.
Differential Revision: https://phabricator.services.mozilla.com/D208931
Also, make them relaxed atomic. Sequentially consistent atomics might
help paper concurrency issues in debug builds, and there's really no
good reason these counts need to be sequentially consistent.
Differential Revision: https://phabricator.services.mozilla.com/D208759
All present uses of the call-site arguments to MozPromise's methods
supply static strings. However, this is nowhere enforced. Do so.
Additionally, since this is the third or fourth time the present author
alone has personally implemented such an enforcement mechanism, create a
helper class to simplify doing so.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D207462
When compiled with -std=c++17, u8"" string literals have type `const char[]`. When compiled with -std=c++20, u8"" string literals have type `const char8_t[]`. This patch adds the minimum char8_t overloads needed to compile Firefox with -std=c++20. If we want to use char8_t in more code or replace `Utf8Unit` with char8_t, that will require an extensive redesign of MFBT's and xpcom's string classes after we update from -std=c++17 to c++20.
Differential Revision: https://phabricator.services.mozilla.com/D201672
The built-in version is better as it also allows annotating particular
parameters (it not only applies to method declarations).
Differential Revision: https://phabricator.services.mozilla.com/D200432
The built-in version is better as it also allows annotating particular
parameters (it not only applies to method declarations).
Differential Revision: https://phabricator.services.mozilla.com/D200432
No functional change. This class is only meant to be instantiated as a
temporary object, and this annotation helps enforce that.
Differential Revision: https://phabricator.services.mozilla.com/D199561
Reasons:
- The copy-constructor is never actually used.
- We already explicitly delete the reassignment operator for this class, which
suggests this class is not really designed to be copied.
- There's not really any good reason for us to make copies of instances of this
class, since this class is just meant to be a lightweight temporary wrapper
to be used only-when-needed, and only at API boundaries to external or legacy
functions.
- When the copy-constructor was used, it triggered a clang
`-Wdeprecated-copy` build warning, for using the default copy constructor
when the reassignment operator was non-default (explicitly deleted).
Differential Revision: https://phabricator.services.mozilla.com/D199383
Performance results pending, but this shouldn't hurt utf-8 atomization
at all, and it should also make utf-16 atomization potentially cheaper.
So sending for review under the assumption that perf numbers will look
good.
Differential Revision: https://phabricator.services.mozilla.com/D189021
Performance results pending, but this shouldn't hurt utf-8 atomization
at all, and it should also make utf-16 atomization potentially cheaper.
So sending for review under the assumption that perf numbers will look
good.
Differential Revision: https://phabricator.services.mozilla.com/D189021
We don't dereference aData, so this is safe in some sense, but
GCC 12 complains about a use-after-free here. In theory, some other
thread could reallocate an object at the same address before
the MOZ_LOG_DTOR call and confuse the leak logging if it is set
to track individual objects, but I don't think that's a realistic
issue.
Differential Revision: https://phabricator.services.mozilla.com/D183508
I saw this in the nightly profile. This makes us go into the string
which in most cases is not necessary because the lengths are different.
Depends on D169143
Differential Revision: https://phabricator.services.mozilla.com/D169144
The main use of this method appears to be when parsing attributes with floating
point values in HTML. By changing from PR_strtod, this change does have some
semantic differences around edge-cases, though I've tried to keep it compliant
with the wording in the standard.
Here are some of the edge-cases I investigated:
1. We appear to build nspr with INFNAN_CHECK undefined, meaning that we did not
parse strings like "inf", "infinity" and "nan" both before and after this
change.
2. PR_strtod already ignored locale (built with USE_LOCALE undefined), so
locale behaviour shouldn't have changed.
3. Neither PR_strtod nor the spec support hex floats, so I didn't enable them
in double-conversion.
4. Leading whitespace is skipped by both PR_strtod and in the spec, so is
skipped after this change.
5. Numbers too large to fit in a double (e.g. 2E308) were previously returned
as inf or -inf by PR_strtod. The spec specifies that these values should return
an error instead, so they have been changed to produce an error with this
change.
This is a web-visible change (<progress value=2E308 max=10> is indeterminate
in Chromium and complete in Firefox before this change, it will be
indeterminate for both after the change).
6. Parsing for floats & doubles are now handled seperately due to
differences in the maximum and minimum representable values.
Differential Revision: https://phabricator.services.mozilla.com/D148305
This will make customizing flags on the regex type less error-prone, as passing
a flag (e.g. `RustRegex::FLAG_CASEI`) will not implicitly disable the default
`UNICODE` flag.
Names and comments were taken from the original `RegexBuilder` type in the
`regex` crate which this type is inspired by, and the type was changed to be
cheaply copyable and support method chaining, so that it can be used more
ergonomically.
Differential Revision: https://phabricator.services.mozilla.com/D159083
This makes the API more ergonomic to use from our c++ code, managing things
like lifecycles automatically.
Documentation comments are copied from the `rure.h` header, and modified
slightly to reflect the C++ types.
Differential Revision: https://phabricator.services.mozilla.com/D158874
This will make customizing flags on the regex type less error-prone, as passing
a flag (e.g. `RustRegex::FLAG_CASEI`) will not implicitly disable the default
`UNICODE` flag.
Names and comments were taken from the original `RegexBuilder` type in the
`regex` crate which this type is inspired by, and the type was changed to be
cheaply copyable and support method chaining, so that it can be used more
ergonomically.
Differential Revision: https://phabricator.services.mozilla.com/D159083
This makes the API more ergonomic to use from our c++ code, managing things
like lifecycles automatically.
Documentation comments are copied from the `rure.h` header, and modified
slightly to reflect the C++ types.
Differential Revision: https://phabricator.services.mozilla.com/D158874
This will make customizing flags on the regex type less error-prone, as passing
a flag (e.g. `RustRegex::FLAG_CASEI`) will not implicitly disable the default
`UNICODE` flag.
Names and comments were taken from the original `RegexBuilder` type in the
`regex` crate which this type is inspired by, and the type was changed to be
cheaply copyable and support method chaining, so that it can be used more
ergonomically.
Depends on D158874
Differential Revision: https://phabricator.services.mozilla.com/D159083
This makes the API more ergonomic to use from our c++ code, managing things
like lifecycles automatically.
Documentation comments are copied from the `rure.h` header, and modified
slightly to reflect the C++ types.
Differential Revision: https://phabricator.services.mozilla.com/D158874
There are only 3 places where nsMemory.h is still needed (image/RasterImage.cpp,
gfx/thebes/gfxFT2FontList.cpp, and nsMemory.cpp). Remove the rest.
Differential Revision: https://phabricator.services.mozilla.com/D158213
The last remaining things requiring unified builds in this directory are the
explicit specializations. As each class' methods are now confined to a single
file, these can now be moved to the appropriate .cpp files.
Differential Revision: https://phabricator.services.mozilla.com/D148303
These files exist only due to the history of how strings were previously
declared using macros, and aren't necessary anymore. The header files were not
removed, as they may be depended on from outside of the module. Cleaning up the
header situation is something which should probably happen in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D148302
The remaining methods in ns[T]StringObsolete are all find+replace methods for
nsTSubstring. These were migrated in a similar way to the find methods, and
partially updated to avoid using methods from nsStringObsolete.cpp.
This change removes the ns[T]StringObsolete.cpp files completely, as they are
no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D148301
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
This patch moves EqualsIgnoreCase to ns[T]StringObsolete, and removes
the aCount argument, instead migrating callers to use `StringBeginsWith`
with a case-insensitive comparator.
In addition, nsTStringRepr::Compare was removed and replaced with either
calls to methods like `StringBeginsWith` or the global `Compare` method.
These changes required some modifications at call-sites but should make
the behaviour less surprising and more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D148299
Due to the history of how nsString was implemented, many APIs ended up being
implemented in inappropriate files. This change moves simple definitions which
won't require any changes for each type to happen within that type's .cpp file.
This is necessary to eventually enable the directory to be built without
unified builds.
Differential Revision: https://phabricator.services.mozilla.com/D148298
This type was introduced in c++17, and can be used as a convenient standard
medium for passing around borrowed substring references. It can be implicitly
converted to from string literals and `const char_type*`, meaning that after
this change it can be used as a convenient catch-all type to replace seperate
overloads for `const self_type&`, `const char_type*` and `const
char_type(&)[N]`.
std::basic_string_view also provides standard implementations of some
algorithms which will be convenient for code cleanup in later parts of this
bug.
Differential Revision: https://phabricator.services.mozilla.com/D148297
This file only exists as a wrapper around nsTSubstring.cpp, with some methods
left in it due to how the string types were defined before they were turned
into templates.
Differential Revision: https://phabricator.services.mozilla.com/D148296
Sylvestre Ledru