Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
I have no idea what the issue is, but this fixes it. I figure it's not
worth putting too much effort into since this was just to make the tests
as DRY as possible, and not actually important.
Differential Revision: https://phabricator.services.mozilla.com/D92237
No longer reset a moved-from Result to an error state, which required
UnusedZero<E>::GetDefaultValue, which was somewhat confusing, and might
also be inefficient. Leaving Result in a valid state, which might be a
success or error state is sufficient.
Differential Revision: https://phabricator.services.mozilla.com/D91250
Per matrix discussion, this is safer to uplift (instead of relying on
the RedirectSink being released on the main thread).
Differential Revision: https://phabricator.services.mozilla.com/D91270
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
mozilla::ReverseIterator is required for "stashing iterators", but otherwise
std::reverse_iterator can be used and is potentially more efficient.
Also fix some other glitches in iterator type definitions.
Differential Revision: https://phabricator.services.mozilla.com/D79489
Previously, the tests assumed that the alignment of int and long equals
their size. This commit fixes the tests for targets like m68k that have
sizeof(int) == 4 and alignof(int) == 2. A static helper function sizemax
was introduced as the offset of the second element in Pair<int,long>
might be either determined by its alignment requirement or the size of
the preceding int element and we use the helper function to pick the
larger of the two values.
Differential Revision: https://phabricator.services.mozilla.com/D77289
Currently, MOZ_ALIGNED_DECL uses the order (_type, _align) for its
parameters. However, this order makes the code less readable when
_type is a larger object like a struct because the value for _align
would be at the end of the struct definition. By swapping the order
of _type and _align, the alignment value will always be next to
the type name, regardless how far the definition of _type extends.
Differential Revision: https://phabricator.services.mozilla.com/D77288
Previously, the tests assumed that the alignment of int and long equals
their size. This commit fixes the tests for targets like m68k that have
sizeof(int) == 4 and alignof(int) == 2. A static helper function sizemax
was introduced as the offset of the second element in Pair<int,long>
might be either determined by its alignment requirement or the size of
the preceding int element and we use the helper function to pick the
larger of the two values.
Depends on D77288
Differential Revision: https://phabricator.services.mozilla.com/D77289
Currently, MOZ_ALIGNED_DECL uses the order (_type, _align) for its
parameters. However, this order makes the code less readable when
_type is a larger object like a struct because the value for _align
would be at the end of the struct definition. By swapping the order
of _type and _align, the alignment value will always be next to
the type name, regardless how far the definition of _type extends.
Depends on D77287
Differential Revision: https://phabricator.services.mozilla.com/D77288
There's no need to provide the compiler a bunch of stuff that it's
trivially going to optimize away anyway, and we'd rather the release
assert not mess with the optimizer's view of the code.
Differential Revision: https://phabricator.services.mozilla.com/D77124
The compiler is not always able to remove these (always-successful)
checks, so we might as well help it along.
Depends on D77122
Differential Revision: https://phabricator.services.mozilla.com/D77123
We're going to introduce some friend declarations in the next patch, and
this change makes doing so easier. It's also slightly less confusing.
Depends on D77121
Differential Revision: https://phabricator.services.mozilla.com/D77122
This also uses MakeUniqueForOverwrite* in two places where we immediately copy
over the Buffer from a Span.
Adds move assignment operator as well.
Differential Revision: https://phabricator.services.mozilla.com/D75510
These are the equivalent of std::make_unique_for_overwrite and std::make_unique_for_overwrite with fallible allocation.
Differential Revision: https://phabricator.services.mozilla.com/D75509
The phrase "copy the error" is misleading, as the error type might not be
copyable, and it is never copied but moved. "Propagate" the error seems to
be a good term to describe this.
Differential Revision: https://phabricator.services.mozilla.com/D75093
The `mozilla::IsPod<HashMapEntry` specialisation was only needed for the static
assertions in "js/src/frontend/NameCollections.h". Part 3 removed those, so we
can now also remove `mozilla::IsPod<HashMapEntry`.
Drive-by change:
- Remove no longer needed "mozilla/PodOperations.h" include in mfbt/HashTable.h.
- And then fix up previously transitively included files for RootingAPI.h,
jsfriendapi.h, and Bench.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D69201
CLOSED TREE
Backed out changeset f42150bdee2b (bug 1626772)
Backed out changeset ab5b637f714a (bug 1626772)
Backed out changeset fd4026a9f380 (bug 1626772)
MOZ_ALWAYS_TRUE() evaluates its expression in both debug and release builds. This bug will change MOZ_ALWAYS_TRUE() to use MOZ_DIAGNOSTIC_ASSERT() instead of MOZ_ASSERT(), so MOZ_DIAGNOSTIC_ALWAYS_TRUE() will be redundant.
Differential Revision: https://phabricator.services.mozilla.com/D66922
--HG--
extra : moz-landing-system : lando
MOZ_ALWAYS_TRUE() evaluates its expression in both debug and release builds. This bug will change MOZ_ALWAYS_TRUE() to use MOZ_DIAGNOSTIC_ASSERT() instead of MOZ_ASSERT() so it will also assert in Nightly and DevEdition release builds.
Differential Revision: https://phabricator.services.mozilla.com/D66921
--HG--
extra : moz-landing-system : lando
MOZ_ALWAYS_TRUE() evaluates its expression in both debug and release builds. This bug will change MOZ_ALWAYS_TRUE() to use MOZ_DIAGNOSTIC_ASSERT() instead of MOZ_ASSERT(), so MOZ_DIAGNOSTIC_ALWAYS_TRUE() will be redundant.
Differential Revision: https://phabricator.services.mozilla.com/D66922
--HG--
extra : moz-landing-system : lando
MOZ_ALWAYS_TRUE() evaluates its expression in both debug and release builds. This bug will change MOZ_ALWAYS_TRUE() to use MOZ_DIAGNOSTIC_ASSERT() instead of MOZ_ASSERT() so it will also assert in Nightly and DevEdition release builds.
Differential Revision: https://phabricator.services.mozilla.com/D66921
--HG--
extra : moz-landing-system : lando
Tests were added as a part of bug 1626471. Expectations that the tests fail
have been removed.
Differential Revision: https://phabricator.services.mozilla.com/D69605
--HG--
extra : moz-landing-system : lando
RC should be non-copyable. It already is non-copyable in the atomic variant,
but not in the non-atomic variant. This ensures that RefCounted is also
non-copyable, which prevents that classes deriving from RefCounted get
accidentally copied.
Also, RC's operator= should be defined only in debug builds. As already
described in a code comment, it's only used in debug builds (to assign the
dead value), and otherwise no modifications other than incrementing &
decrementing should be possible.
Differential Revision: https://phabricator.services.mozilla.com/D69332
--HG--
extra : moz-landing-system : lando
RC should be non-copyable. It already is non-copyable in the atomic variant,
but not in the non-atomic variant. This ensures that RefCounted is also
non-copyable, which prevents that classes deriving from RefCounted get
accidentally copied.
Also, RC's operator= should be defined only in debug builds. As already
described in a code comment, it's only used in debug builds (to assign the
dead value), and otherwise no modifications other than incrementing &
decrementing should be possible.
Differential Revision: https://phabricator.services.mozilla.com/D69332
--HG--
extra : moz-landing-system : lando
Also removes the comment which allows adding more `AbsReturnType` specialisations,
because that shouldn't be necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D68569
--HG--
extra : moz-landing-system : lando
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
--HG--
extra : moz-landing-system : lando
Dorel Luca
Ricky Stewart
Christian Holler
Cameron McCormack
Sylvestre Ledru
Simon Giesecke
Paul Bone
Alexis Beingessner
Emilio Cobos Álvarez
Bogdan Tara
Butkovits Atila
Csoregi Natalia
Razvan Maries
Gerald Squelart
Jan Varga
Kartikaya Gupta
Jeff Gilbert
Eugen Sawin
Tom Ritter
David Major
Kagami Sascha Rosylight
Ryan VanderMeulen
Nathan Froyd
Chris Martin
Mihai Alexandru Michis
Chris Peterson
Frederik Braun
Jean-Yves Avenard
Nick Alexander
june wilde
Mike Hommey
John Paul Adrian Glaubitz
Brindusan Cristian
Chris Fronk
Jon Bauman
Bob Owen
Greg V
Shishir Jaiswal
Andrew McCreight
Eric Rahm
André Bargull
Steve Fink
Sebastian Hengst
Timothy Gu
Narcis Beleuzu
Gurzau Raul