This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
The VisualViewport events are all nice and shiny, but unfortunately not quite
what is needed for the session store.
Firstly, the spec wants the "scroll" event to be fired only when the *relative*
offset between visual and layout viewport changes. The session store however
records the absolute offset and as such is interested in when *that* changes.
Secondly, again as per the spec the events don't bubble, and with the default
DOMEventTargetHelper implementation they don't escape the VisualViewport during
capturing, either. This means that any event listener must be added directly on
the VisualViewport itself in order to capture any events.
This might have been intended because the events use the same names as the
normal "scroll"/"resize" events, and as such you cannot specify separate event
listeners for VisualViewport and non-VisualViewport "scroll" events if both
events end up being dispatched to the same element (you can only try to filter
after the fact by looking at the originalTarget of the event).
At the same time, the VisualViewport is attached to the inner Window, and so
each time you navigate, you also get a different VisualViewport object.
All of this might be totally fine from the perspective of a page script, because
in that case you won't care anyway about what happens when the current page goes
away.
From the session store perspective on the other hand (especially Fennec's non-
e10s session store design), this is rather unfortunate because we don't want to
have to keep registering event listeners
a) manually for each subframe
b) each time the page navigates
The event target chain problem could be solved by letting the scroll events
escape the VisualViewport during the capturing phase (which the spec doesn't say
anything about), but this would mean that any scroll listener attached to a
window/browser/... that uses capturing will now catch both layout and visual
viewport scroll events.
In some cases this might even be beneficial, but in others (e.g. bug 1498812
comment 21) I'd like to specifically decide which kind of scroll event to
capture. Having to look at event.originalTarget to distinguish the two kinds
might be defensible in test code, but in case this distinction would be needed
in production code as well, given the existence of a C++-based filtering helper
in nsSessionStoreUtils for another use case where (scroll) events need to be
filtered, JS-based scroll event filtering might be a bad idea.
Additionally, in any case this wouldn't solve the fundamental conflict between
the spec and the session store about *when* the "scroll" event should be fired
in the first place.
Hence I'd like to introduce a separate set of events with distinct event names,
which will be dispatched according to the requirements of our internal users
(i.e. currently the session store). To avoid potential web compatibility issues
down the road, for now these events will be dispatched only to event listeners
registered in the system group (allowing *all* Chrome event listeners cannot be
done because checking the Chrome status of each event target might be too
expensive for frequently dispatched events).
Differential Revision: https://phabricator.services.mozilla.com/D14046
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
Clang format does not always reflow comments correctly to get them
within 80 columns.
The major categories of failures I have noticed in xpcom/ are:
- Comments that are lists. I fixed these by manually getting them so
they'll be within 80 columns after clang-format runs.
- Comments intermixed with lists of things like enums, initializers,
or even fields in a class. It doesn't seem to associate the comment
with the item in the list correctly. The worst cases of these happen
when it changes initializer lists from having commas at the start of
each item to having them at the end. In the initializer comma cases,
I fixed them by making the commas at the end, so clang-format won't
mix things up. For other cases, I often moved the comment for an
item onto its own line, because it was not possible to have both the
comment and the item on the same line and stay within 80 columns.
- One odd case is nsEnumeratorUtils.cpp, where the end of line comment
after a NS_DECL macro confused clang-format and made it stop
realizing that the NS_DECL thing was a complete statement. I also
added a blank line to that file before a declaration because I think
that is better.
Depends on D13183
Differential Revision: https://phabricator.services.mozilla.com/D13184
--HG--
extra : moz-landing-system : lando
Clang format makes this code look pretty bad, but I think it is safe
to just remove it.
Depends on D13182
Differential Revision: https://phabricator.services.mozilla.com/D13183
--HG--
extra : moz-landing-system : lando
We're paying two function calls from Gecko_AddRefAtom /
Gecko_ReleaseAtom for no good reason, plus it's simple enough it's probably
worth to inline it anyway for C++ callers.
Differential Revision: https://phabricator.services.mozilla.com/D12860
--HG--
extra : moz-landing-system : lando
The core loop of Iterator::Next() requires multiple branches, one to
check for entry liveness and one to check for wraparound. We can
rewrite this to use masking instead, as well as iterating only over the
hashes, and reconstructing the entry pointer when we know we've reached
a live entry. This change cuts the time taken on the collections
benchmark by the iteration portion in half.
As discussed in the previous commit message, PLDHashTable's storage
wastes space for common entry types. This commit reorganizes the
storage to store all the hashes packed together, followed by all the
entries, which eliminates said waste.
PLDHashTable requires that all items stored therein inherit from
PLDHashEntryHdr:
struct PLDHashEntryHdr {
// PLDHashNumber is a uint32_t.
PLDHashNumber mKeyHash; // Cached hash key for object.
};
class MyType : public PLDHashEntryHdr {
// Data members, etc.
};
PLDHashEntryHdr::mKeyHash is used to cache the computed hash value of
the entry, so we aren't rehashing entries on every lookup/add/etc.
Because of structure layout requirements on 64-bit platforms, the data
members of MyType will typically start at offset 8:
MyType, offset 0: mKeyHash
MyType, offset 4: padding required by alignment
MyType, offset 8: first data member of MyType
MyType, offset N: ...
The padding at offset 4 is dead, unused space.
We'd like to change this state of affairs by having PLDHashTable manage
the cached hash key itself, which would eliminate the dead space in the
object and would enable packing the table storage more tightly. But
PLDHashTable pervasively assumes that its internal storage is an array
of PLDHashEntryHdrs (with an associated object size to account for
subclassing).
As a first step to laying out the hash table storage differently, we
have to make the internals of PLDHashTable not access PLDHashEntryHdr
items directly, but layer an abstraction on top. We call this
abstraction "slots": a slot represents storage for the cached hash key
and the associated entry, and can produce a PLDHashEntryHdr* on demand.
The only place where this is used where the const-ness matters is in
AddressEntry, and that use const_cast's away the const-ness. So let's
just ditch the method that attempts to return const pointers.
This change is satisfying insofar as it removes a load from every
iteration step over the hashtable, but it doesn't seem to affect
our collection benchmarks in any way. The change does not make
iterators any larger, as there is padding at the end of the iterator
structure on both 32- and 64-bit platforms.
This refactors the observer service code to improve readability, uses MOZ_TRY
and other checking macros wherever possible to simplify error handling and
replaces the ObserverRef class with the more generic nsMaybeWeakPtr class.
This cuts away some code and halves the amount of memory needed to store an
event listener. The external behavior is almost unchanged save for some error
codes which are now more specific.
Differential Revision: https://phabricator.services.mozilla.com/D11646
--HG--
extra : source : 10d910aa9f31435116a718bafe8a2b71c61fe23d
We only use its value in one place, and said value is easily computable
from readily available information. This change makes iterators
slightly smaller.
This adds a new class for the marquee tag, instead of overloading HTMLDivElement.
It removes some of the XBL that was used to expose properties to web content.
Differential Revision: https://phabricator.services.mozilla.com/D3824
--HG--
extra : moz-landing-system : lando
And thus massively speed up ascii-case-insensitive atom comparisons when both
atoms are lowercase (which is the common case by far).
This removes almost all the slow selector-matching in this page, and it seems
an easier fix than storing the lowercased version of all class-names in quirks
mode in elements and selectors...
Differential Revision: https://phabricator.services.mozilla.com/D10945
--HG--
extra : moz-landing-system : lando
This is a rebase + manual refcounting on some places, + cleanup of the original
patch in the bug.
Co-authored-by: Nicholas Nethercote <nnethercote@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D11035
Other frames calling InitAndWrapInColumnSetFrameIfNeeded() needs to be
modified to support column-span (bug 1489295).
Depends on D5208
Differential Revision: https://phabricator.services.mozilla.com/D5209
--HG--
extra : moz-landing-system : lando
Move XUL persistence handling into it's own class and make it a separate
nsIDocumentObserver so it can also be used in non-XUL documents.
To avoid adding persistence to all non-XUL documents, a document must add
the "mozpersist" attribute to the root element if it wants enable the
feature.
Differential Revision: https://phabricator.services.mozilla.com/D6802
--HG--
extra : moz-landing-system : lando
This is needed for bug 1500926. It takes the approach of taking a JSFlatString
and using AutoAssertCannotGC to read the memory directly from the JS heap.
This lets us avoid re-encoding strings when performing lookups, which can be
advantageous.
Only ASCII strings are supported by this handler, and wide strings are hashed
as though they contain only values under 0x7f. This is OK as invalid keys to
perfecthash may return any hashtable entry.
Differential Revision: https://phabricator.services.mozilla.com/D9405
This commit adds a scroll origin, nsGkAtoms::relative, which can be used to
mark main thread scrolling that can be combined with a concurrent APZ scroll.
The behavior of this is controlled by a pref, apz.relative-update. This pref
is initially activated and is intended as an aid to narrowing down causes
of regressions for users in bug reports.
Relative scroll updates work by tracking the last sent or accepted APZ
scroll offset. This is sent along with every FrameMetrics. Additionally,
a flag is added to FrameMetrics, mIsRelative, indicating whether the
scroll offset can be combined with a potential APZ scroll. When this
flag is set, AsyncPanZoomController will apply the delta between the sent
base scroll offset, and sent new scroll offset.
This flag is controlled by the last scroll origin on nsGfxScrollFrame. The
new origin, `relative`, is marked as being able to clobber APZ updates,
but can only be set if all scrolls since the last repaint request or
layers transaction have been relative.
Differential Revision: https://phabricator.services.mozilla.com/D8234
--HG--
extra : rebase_source : 51351a84c9cda228a0975e22eda3fd3bd8d261c4
extra : histedit_source : 4b564c19b16fe2bd26adc671b62b7cb6106e8163
Specifically:
- nsICSSAnonBoxPseudo --> nsCSSAnonBoxPseudoStaticAtom
- nsICSSPseudoElement --> nsCSSPseudoElementStaticAtom
The `nsI` prefix isn't necessary because these are no longer XPIDL types, and
the `StaticAtom` suffix makes their meaning clearer.
--HG--
extra : rebase_source : b68dd7c73f5036dcd6be4c3700b757441f59f9f2
This saves one word per static atom, per process.
The `nsGkAtoms` change is only a small part of this commit.
In regen_atoms.py:
- There is now only one link name per platform: nsGkAtoms::sAtoms[].
- But there is a new constant per atom, giving the index into
nsGkAtoms::sAtoms[].
- And the `atom!` macro for each atom indexes into nsGkAtoms::sAtoms[] using
the index constant.
- A couple of `*mut` pointers are now `*const`.
Elsewhere, the `(nsStaticAtom*)` casts within the `AppendElement()` calls are
necessary to avoid link errors, presumably due to some template instantiation
wrinkle.
--HG--
extra : rebase_source : 629642e708c8bc6e27d6057beae5f35955fdd837
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
Presumably the commit that introduced `aStringOffset` could have removed this,
but overlooked it.
--HG--
extra : rebase_source : 176f14ce01c18ed4c83892d2b7a9e7a54fb5c836
Static atom registration is a bit of a mess. NS_InitAtomTable() calls
nsGkAtoms::RegisterStaticAtoms(), which calls NS_RegisterStaticAtoms(); i.e. we
go from nsAtomTable.cpp to nsGkAtoms.cpp and back.
(And NS_RegisterStaticAtoms() is declared in a .cpp file, not a .h file!)
This commit makes NS_InitAtomTable() a friend of nsGkAtoms, so NS_InitAtomTable
can see nsGkAtoms's atoms array directly, thus removing the need for
NS_RegisterAtomTable() and nsGkAtoms::RegisterStaticAtoms().
This commit also removes an out-of-date part of a comment from XPCOMInit.cpp.
--HG--
extra : rebase_source : 7e1f9aa0a9f7cb5088159fe4c953948b931f6d68
nsGkAtoms.h has a big comment explaining how static atom definitions get
expanded by macros. This comment was very useful when there were multiple
sources of static atoms and their definitions used macros a lot. But bug
1482782 combined all the static atom sources into nsGkAtoms and removed a lot
of macro use. So now the comment is now something of a hindrance, duplicating
quite a bit of the code (and not entirely accurately).
This commit removes the big comment, and moves the still-useful parts inline
with the code. This makes things much easier to follow.
This commit also reformats some of the remaining macros so they are easier to
read.
--HG--
extra : rebase_source : 4377be2fa0edc4ea1f592985ded89acbb76fb104
Replace mozilla.widget.use-argb-visuals pref by -moz-gtk-csd-transparent-background media query at browser.css
to draw transparent background. The media query is set by toolkit code and enabled when compatible
window manager is detected.
Differential Revision: https://phabricator.services.mozilla.com/D6658
--HG--
extra : moz-landing-system : lando
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the
place. Additionally, if moving entries is implemented via memcpy (which
is quite common), PLDHashTable copying around bits *again* is
inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead of
copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
This switches over the few remaining usages of the deprecated
BeginWriting/EndWriting(iterator&) functions to the more standard
BeginWriting/EndWriting() functions.
--HG--
extra : rebase_source : 3c54621d4921eb45157ec4edce0b693bdd7f02d5
This adds a most recently used cache that can be used as a quick lookup table
for frequently used entries.
--HG--
extra : rebase_source : 571c32f75e985e299113f73b959809d208aad5f3
* Avoid the string implementation's capacity checks, since we know they
succeed.
* Avoid the string implementation's aliasing checks, since we know there's no
aliasing.
* Avoid writing the zero terminator more than once or out of sequence.
* Use u"" literals when appending literals to a UTF-16 string.
* Write runs of non-escaped code units instead of writing code unit by code
unit in order to benefit from SIMD (either via memcpy or
ConvertLatin1toUTF16).
This results in a 13% execution time reduction on desktop Haswell i7 when
getting the innerHTML of the body of the Selectors spec. (The WebKit
optimization target from https://bugs.webkit.org/show_bug.cgi?id=81214 .)
MozReview-Commit-ID: LAg3gkGJnpQ
Differential Revision: https://phabricator.services.mozilla.com/D5239
--HG--
extra : moz-landing-system : lando
In many places, nsTArray::IndexOf is followed by accessing that element
(hopefully with `Elements() + index`, which skips unnecessary bounds checks.)
But this pattern introduces operations that could be avoided:
- IndexOf converts the address of the found element into an index,
- The caller must test for a special `NoIndex` value,
- On success, accesses convert that index back into the original address.
This patch introduces new 'ApplyIf...' functions that combine all these
operations in a more efficient ensemble: If the sought element is found, it is
passed by reference to a given callable object (usually a lambda); if not
found, another callable is invoked.
Depending on what they need, the first callable may take one of these parameter
lists: (), (size_t), (maybe-const elem_type&), (size_t, maybe-const elem_type&).
On top of removing the pointer->index->pointer operations in most cases,
invoking callables directly from ApplyIf is safer, as the array is guaranteed to
be untouched at this time.
Also, being templates taking function objects, in most cases the compiler should
be able to inline and optimize the search and its callables' code.
This patch gives example uses in nsTArray::Contains, and in
FrameProperties::GetInternal, SetInternal.
And FrameProperties::Has now calls Contains, which is more efficient because
the former code would compute an index (or NoIndex), and then convert that index
to a bool; whereas the new code directly produces a bool from within the search
algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D2758
--HG--
extra : moz-landing-system : lando
The 'x' prefix makes it clearer that these are infallible.
A couple of nsJSID methods are now also infallible.
--HG--
extra : rebase_source : fcce44a00212d6d341afbf3827b31bd4f7355ad5
There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
This patch adds simple stubs to convert between the nsISimpleEnumerator
iteration protocol and the JS iteration protocol.
Each iterable object is required to have an @@iterator method which returns an
object implementing the iterator protocol. The later objects, by convention,
also have such a method which returns the object itself.
This patch adds both a @@iterator() and entries() methods to
nsISimpleEnumerator. The former returns an iterator which returns plain
nsISupports objects. The latter accepts an IID and queries each element to
that IID before returning it. If any element fails to query, the error is
propagated to the caller.
Differential Revision: https://phabricator.services.mozilla.com/D3727
--HG--
extra : rebase_source : 340eb43a1c5e6d7ae69fa8ee486d66d31d079b14
extra : histedit_source : f3efc6c265851a563968ee410e4626e0540f55c0
The nsISimpleEnumerator contract specifies that GetNext() returns
NS_ERROR_FAILURE when iteration is complete. Several implementations, however,
either return NS_OK and a null result, or return some other error code, when
iteration is complete.
Since my initial implementation of the JS iteration stubs rely on the
contract-defined behavior of GetNext(), these need to be fixed before it can
land.
Differential Revision: https://phabricator.services.mozilla.com/D3726
--HG--
extra : rebase_source : aab0395df52e18ccff5b0a2489a983013bf484b1
extra : histedit_source : a5644f0a88799b4463af9dd01dfec33b373b1f58
In order to allow JS callers to use nsISimpleEnumerator instances with the JS
iteration protocol, we'll need to additional methods to every instance. Since
we currently have a large number of unrelated implementations, it would be
best if they could share the same implementation for the JS portion of the
protocol.
This patch adds a stub nsSimpleEnumerator base class, and updates all existing
implementations to inherit from it. A follow-up will add a new base interface
to this class, and implement the additional functionality required for JS
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D3725
--HG--
extra : rebase_source : ad66d7b266856d5a750c772e4710679fab9434b1
extra : histedit_source : a83ebffbf2f0b191ba7de9007f73def6b9a955b8
In order to implement profile-per-install we need a mutable INI parser in early
startup. The current one is implemented in JavaScript and thus not available.
This makes the current read-only C++ INI parser mutable and removes the
JavaScript implementation.
It turns out that the two different implementations of nsIINIParserFactory and
nsIINIParser behaved slightly differently but only in ways that the single test
cared about so I've adjusted things a little to make it work.
The existing C++ implementation did not do validity checks on arguments, this
adds that making empty sections and values illegal.
Differential Revision: https://phabricator.services.mozilla.com/D3851
--HG--
rename : xpcom/tests/unit/test_iniProcessor.js => xpcom/tests/unit/test_iniParser.js
extra : source : 524941c8ed0e048ee51be1bd11082b41428ef490
extra : amend_source : 2de6cef5be97448a41733bedda29d6af34aed27a
Now that :-moz-system-metric is gone, there's no real reason for the atoms to
be separate.
Differential Revision: https://phabricator.services.mozilla.com/D3497
--HG--
extra : moz-landing-system : lando
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
Summary:
This is a streamlined version of perfecthash.py from xpcom/reflect/xptinfo.
There are a few major changes here:
Instead of providing '(key, value)' pairs to the constructor, callers provide a
list of 'entries'. An optional 'key' parameter allows overriding the function
used to get an entry's key. The default behaviour is as before, destructuring a
(key, value) tuple.
Keys can now be anything which supports the 'memoryview' protocol with 1-byte
elements, rather than being forced to be a 'bytearray'. This allows passing in
types such as bytestrings.
A new 'cxx_codegen' method is now exposed which generates a series of
fully-contained C++ declarations to perform entry lookups. It is possible to
override many parts of this codegen to make it the best fit for your component.
PerfectHash remembers the 'key' function, meaning lookup methods automatically
verify a valid key was passed in, and return 'None' otherwise.
Depends On D2615
Reviewers: froydnj!
Tags: #secure-revision
Bug #: 1479484
Differential Revision: https://phabricator.services.mozilla.com/D2616
Summary:
The plan is to also expose perfecthash.py from this module on the python path.
This also allows us to stop using explicit module loading to load make_dafsa.py.
make_dafsa.py was moved into tools/ to avoid any extra python files from
accidentally ending up on the python path.
Reviewers: froydnj!
Tags: #secure-revision
Bug #: 1479484
Differential Revision: https://phabricator.services.mozilla.com/D2614
--HG--
rename : xpcom/ds/make_dafsa.py => xpcom/ds/tools/make_dafsa.py
Summary:
This is done so we can use Array as the name for the new nsTArray-based
type, rather than having to come up with a new name.
LegacyArray was chosen as the [array] attribute is now effectively deprecated,
and we'd like to remove it ASAP.
Depends On D2334
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2335
Currently we have three ways of representing hash values.
- uint32_t: used in HashFunctions.h.
- PLDHashNumber: defined in PLDHashTable.{h,cpp}.
- js::HashNumber: defined in js/public/Utility.h.
Functions that create hash values with functions from HashFunctions.h use a mix
of these three types. It's a bit of a mess.
This patch introduces mozilla::HashNumber, and redefines PLDHashNumber and
js::HashNumber as synonyms. It also changes HashFunctions.h to use
mozilla::HashNumber throughout instead of uint32_t.
This leaves plenty of places that still use uint32_t that should use
mozilla::HashNumber or one of its synonyms, but I didn't want to tackle that
now.
The patch also:
- Does similar things for the constants defining the number of bits in each
hash number type.
- Moves js::HashNumber from Utility.h to HashTable.h, which is a better spot
for it. (This required changing the signature of ScrambleHashCode(); that's
ok, it'll get moved by the next patch anyway.)
MozReview-Commit-ID: EdoWlCm7OUC
--HG--
extra : rebase_source : 5b92c0c3560eb56850cd8832f8ee514d25e3c16f
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle
that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the place.
Additionally, if moving entries is implemented via memcpy (which is
quite common), PLDHashTable copying around bits *again* is inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead
of copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
Summary:
This is done so we can use Array as the name for the new nsTArray-based
type, rather than having to come up with a new name.
LegacyArray was chosen as the [array] attribute is now effectively deprecated,
and we'd like to remove it ASAP.
Depends On D2334
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2335
When removing an element that exists in the array, there's no need to
perform extra bounds checks for actually removing the element; the
presence of the element guarantees that we have a valid index and a
valid range to remove. So split RemoveElementsAt into a safe interface
and an unsafe interface, and let RemoveElement call the latter as an
internal optimization. The same logic applies to RemoveElementSorted.
We call RemoveElement depressingly often, so this is a nice little win.
Cosmin Sabou
Martin Stransky
xftroxgpx
Ehsan Akhgari
Cameron McCormack
quasicomputational
Jan Henning
Nathan Froyd
Jonathan Kingston
Andrea Marchesini
Sylvestre Ledru
Emilio Cobos Álvarez
Brian Hackett
Andreea Pavel
Andrew McCreight
Gabriele Svelto
Tim Nguyen
Paolo Amadini
Boris Zbarsky
Nika Layzell
Brian Grinstead
Ting-Yu Lin
Brendan Dahl
Ryan Hunt
Mats Palmgren
Nicholas Nethercote
Jonathan Watt
Gurzau Raul
Narcis Beleuzu
Kris Maglione
Eric Rahm
Marcos Cáceres
shindli
Coroiu Cristina
Gijs Kruitbosch
Marcos Cáceres
Hiroyuki Ikezoe
arthur.iakab
Henri Sivonen
Zibi Braniecki
Margareta Eliza Balazs
Gerald Squelart
Dave Townsend
Csoregi Natalia
Andrew Osmond