Among other things, there were some misuses of std::forward, and
GenericErrorResult was (presumably accidentally) instatiated with
references as the template argument type, e.g. const nsresult&,
which circumvented the check for not calling it with NS_OK in
ResultExtensions.h
Differential Revision: https://phabricator.services.mozilla.com/D90561
Among other things, there were some misuses of std::forward, and
GenericErrorResult was (presumably accidentally) instatiated with
references as the template argument type, e.g. const nsresult&,
which circumvented the check for not calling it with NS_OK in
ResultExtensions.h
Differential Revision: https://phabricator.services.mozilla.com/D90561
In most situations, JSONWriter users already know string lengths (either directly, or through `nsCString` and friends), so we should keep this information through JSONWriter and not recompute it again.
This also allows using JSONWriter with sub-strings (e.g., from a bigger buffer), without having to create null-terminated strings.
Public JSONWriter functions have overloads that accept literal strings.
Differential Revision: https://phabricator.services.mozilla.com/D86192
It seems that the clang toolchain has trouble optimizing away the tag access in
a `mozilla::Variant`. Use of a `CompactPair` seems to be better when `E` is
small (all cases where `UnusedZero<E>` is true are small right now anyway).
While this doesn't change `sizeof(Result<V, E>)` in most cases, it makes
the generated code simpler/smaller: As of now, this reduce the overall VM size
of libxul.so by ca. 59K.
Without additional effort, this requires and leads to default-construction of
a `V` even in cases where it is never accessed, so this is restricted to
trivially default-constructible `V` for now.
This could be avoided by replacing `CompactPair<V, E>` by
`CompactPair<AlignedStorage2<V>, E>`.
Differential Revision: https://phabricator.services.mozilla.com/D88393
It seems that the clang toolchain has trouble optimizing away the tag access in
a `mozilla::Variant`. Use of a `CompactPair` seems to be better when `E` is
small (all cases where `UnusedZero<E>` is true are small right now anyway).
While this doesn't change `sizeof(Result<V, E>)` in most cases, it makes
the generated code simpler/smaller: As of now, this reduce the overall VM size
of libxul.so by ca. 59K.
Without additional effort, this requires and leads to default-construction of
a `V` even in cases where it is never accessed, so this is restricted to
trivially default-constructible `V` for now.
This could be avoided by replacing `CompactPair<V, E>` by
`CompactPair<AlignedStorage2<V>, E>`.
Differential Revision: https://phabricator.services.mozilla.com/D88393
Also, remove the existing uses of Result<const nsCString, nsresult> in URLPreloader
and Result<CryptoScheme, const nsCString> in SampleIterator.
Differential Revision: https://phabricator.services.mozilla.com/D88419
The patch:
- Changes from an explicit capture in MOZ_VALIDATE_AND_GET_HELPER3/MOZ_IS_VALID
to a default capture, to support referencing local variables in conditions.
- Moves things around in Tainting.h and adds comments
- Adds unit tests for the macros
Differential Revision: https://phabricator.services.mozilla.com/D85889
Content processes will now receive cached values for GetFontImpl() from the
parent process during initialization and whenever the theme changes.
This eliminates the use of several Win32k calls in content.
Differential Revision: https://phabricator.services.mozilla.com/D83406
CLOSED TREE
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
We don't need these macros anymore, for two reasons:
1. We have static analysis to provide the same sort of checks via `MOZ_RAII`
and friends.
2. clang now warns for the "temporary that should have been a declaration" case.
The extra requirements on class construction also show up during debug tests
as performance problems.
This change was automated by using the following sed script:
```
# Remove declarations in classes.
/MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER/d
/MOZ_GUARD_OBJECT_NOTIFIER_INIT/d
# Remove individual macros, carefully.
{
# We don't have to worry about substrings here because the closing
# parenthesis "anchors" the match.
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_TO_PARENT)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_PARAM_IN_IMPL)/)/g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_IN_IMPL)/)/g;
# Remove the longer identifier first.
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM_TO_PARENT//g;
s/MOZ_GUARD_OBJECT_NOTIFIER_ONLY_PARAM//g;
}
# Remove the actual include.
\@# *include "mozilla/GuardObjects.h"@d
```
and running:
```
find . -name \*.cpp -o -name \*.h | grep -v 'GuardObjects.h' |xargs sed -i -f script 2>/dev/null
mach clang-format
```
Differential Revision: https://phabricator.services.mozilla.com/D85168
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
* Use clearer pref names.
* Default (and only support) IPDL dispatching.
* Make DispatchCommands async-only.
* Sync ipdl command per sync webgl entrypoint.
* Eat the boilerplate cost, since there's not too many.
* Run SerializedSize off same path as Serialize.
* All shmem uploads go through normal DispatchCommands.
* Defer pruning of dead code for now so we can iterate quickly.
* Use Read/Write(begin,end) instead of (begin,size).
* This would have prevented a bug where we read/wrote N*sizeof(T)*sizeof(T).
Differential Revision: https://phabricator.services.mozilla.com/D81495
It worked until now as IPC's MessageChannel was only used with background taskqueue; which use a threadpool made of a single thread only.
Differential Revision: https://phabricator.services.mozilla.com/D82499
It worked until now as IPC's MessageChannel was only used with background taskqueue; which use a threadpool made of a single thread only.
Differential Revision: https://phabricator.services.mozilla.com/D82499
Here "update programs" refers to the various standalone binaries we
produce in order to update Firefox. There's not strong conceptual
coherence between them; rather, it's the pieces that the
Install/Update team generally work on.
To use this build project, prepare a minimal mozconfig with
`--enable-project=tools/update-programs`. Depending on the mozconfig
options and host and target OS, some of the following will be built:
1. the maintenance service;
2. the updater binary;
3. the Windows Default Browser Agent;
4. the Background Update Agent.
Differential Revision: https://phabricator.services.mozilla.com/D82644
It worked until now as IPC's MessageChannel was only used with background taskqueue; which use a threadpool made of a single thread only.
Differential Revision: https://phabricator.services.mozilla.com/D82499
It worked until now as IPC's MessageChannel was only used with background taskqueue; which use a threadpool made of a single thread only.
Differential Revision: https://phabricator.services.mozilla.com/D82499
This was previously r=jchen and landed, but was backed out because some
Android tests were running on an unrealistically old Linux kernel. These
tests have been retired, so this can reland.
Differential Revision: https://phabricator.services.mozilla.com/D81278
I will admit from the start that this patch is goofy and is not the "proper" fix.
If you're unlucky enough to tickle the current unification in `dom/media`, then there's a conflict between `namespace mozilla::details` of `SPSCQueue.h` and `namespace details` of Chromium's `task.h`. Ultimately, the badness stems from some unified file doing `using namespace mozilla;`, but I'm really not enthusiastic about reworking that when I just want to get unblocked.
I'm going to attempt to justify the yuckiness of this patch on the basis that:
* `SPSCQueue.h` is super self-contained and rarely looked at, I bet nobody will notice this change
* Tons of other code prefers the spelling `mozilla::detail` anyway
Differential Revision: https://phabricator.services.mozilla.com/D81162
The following simplifications are made:
* Unnecessary function template arguments are removed.
* Unnecessary copy constructor definitions are removed (making the types
movable where possible).
* Iterators are moved where possible rather than copied.
* Unnecessary MOZ_IMPLICIT on a constructor with two arguments is removed.
Differential Revision: https://phabricator.services.mozilla.com/D80015
The following simplifications are made:
* Unnecessary function template arguments are removed.
* Unnecessary copy constructor definitions are removed (making the types
movable where possible).
* Iterators are moved where possible rather than copied.
* Unnecessary MOZ_IMPLICIT on a constructor with two arguments is removed.
Differential Revision: https://phabricator.services.mozilla.com/D80015