Commit Graph
13 Commits
Author SHA1 Message Date
Andi-Bogdan Postelnicu fccbbc6b44 Bug 1660405 - Move away from mozilla::IsFinite in favor of std::isfinite. r=sergesanspaille
Differential Revision: https://phabricator.services.mozilla.com/D173036
2023-03-22 11:35:33 +00:00
Stanca Serban 98c675ed3f Backed out 7 changesets (bug 1660405) for causing bustages on Linux x64 opt. CLOSED TREE
Backed out changeset ad1a5f59214f (bug 1660405)
Backed out changeset a39e95f0aafe (bug 1660405)
Backed out changeset 48629ee0d70d (bug 1660405)
Backed out changeset 8419b99aab60 (bug 1660405)
Backed out changeset 535cc12c8bed (bug 1660405)
Backed out changeset e27052da4927 (bug 1660405)
Backed out changeset 11b0f9cf8091 (bug 1660405)
2023-03-22 13:05:53 +02:00
Andi-Bogdan Postelnicu 2e64d79ba8 Bug 1660405 - Move away from mozilla::IsFinite in favor of std::isfinite. r=sergesanspaille
Differential Revision: https://phabricator.services.mozilla.com/D173036
2023-03-22 09:27:57 +00:00
Nika Layzell 605a423c5c Bug 840706 - Part 2: Make ToDouble and ToFloat more spec-compliant, r=smaug,xpcom-reviewers,barret
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
2022-12-06 20:27:49 +00:00
Nika Layzell 51c14166ec Bug 1772006 - Part 8: Allow building xpcom/string without unified builds, r=xpcom-reviewers,barret
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
2022-07-30 00:12:49 +00:00
Nika Layzell 63a28ee824 Bug 1772006 - Part 5: Simplify and move the string searching APIs from ns[T]StringObsolete, r=xpcom-reviewers,necko-reviewers,eeejay,dragana,barret
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
2022-07-30 00:12:48 +00:00
Nika Layzell b14d1318e0 Bug 1772006 - Part 4: Simplify and move the string comparison APIs from ns[T]StringObsolete, r=xpcom-reviewers,necko-reviewers,dragana,barret
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
2022-07-30 00:12:48 +00:00
Nika Layzell 86f2e82c25 Bug 1772006 - Part 3: Move basic string APIs to more appropriate .cpp files, r=xpcom-reviewers,barret
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
2022-07-30 00:12:47 +00:00
criss c1b045ddda Backed out 9 changesets (bug 1772006) causing build bustages on nsTString.cpp. CLOSED TREE
Backed out changeset f17c7565707b (bug 1772006)
Backed out changeset c725fe1f5882 (bug 1772006)
Backed out changeset d19663161261 (bug 1772006)
Backed out changeset b6611ab002d9 (bug 1772006)
Backed out changeset 790f42b64af9 (bug 1772006)
Backed out changeset 79a734b4e4d9 (bug 1772006)
Backed out changeset 42730aae16ea (bug 1772006)
Backed out changeset b2542aef3054 (bug 1772006)
Backed out changeset 962bfea4a309 (bug 1772006)
2022-06-11 01:13:42 +03:00
Nika Layzell 25f92a45e7 Bug 1772006 - Part 9: Allow building xpcom/string without unified builds, r=xpcom-reviewers,barret
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
2022-06-10 21:12:09 +00:00
Nika Layzell c1e4a1e52c Bug 1772006 - Part 6: Simplify and move the string searching APIs from ns[T]StringObsolete, r=xpcom-reviewers,necko-reviewers,eeejay,dragana,barret
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
2022-06-10 21:12:08 +00:00
Nika Layzell fe77bb85a8 Bug 1772006 - Part 5: Simplify and move the string comparison APIs from ns[T]StringObsolete, r=xpcom-reviewers,necko-reviewers,dragana,barret
In addition to moving these methods to a more appropriate file, they were
simplified to make them easier to maintain in the future.
nsTStringRepr::Compare was extended to also work on char16_t strings, and the
case insensitive and other options were removed as they aren't necessary. This
required some changes to callers in the tree.

The EqualsIgnoreCase method was also simplified by using `std::string_view`.

Differential Revision: https://phabricator.services.mozilla.com/D148299
2022-06-10 21:12:07 +00:00
Nika Layzell f753a5d8e9 Bug 1772006 - Part 4: Move basic string APIs to more appropriate .cpp files, r=xpcom-reviewers,barret
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
2022-06-10 21:12:07 +00:00