Similar to the previous part, we convert mBreakpadId to an nsCString to
avoid issues with locale-dependent std::string operations.
There are a lot of non-profiler changes here because a bunch of things
depend on the SharedLibrary object that the profiler defines.
Using operator<< on stringstream on Windows dives into the registry for
locale-specific formatting details. This behavior is neither desired
or (probably) anticipated by the code. Instead, let's use our normal
Gecko string classes for SharedLibrary::mVersion.
The check finds assignments of an integer to std::string:
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-string-integer-assignment.html
There are currently ten misc-string-integer-assignment warnings in mozilla-central, but they are all in third-party Breakpad code:
toolkit/crashreporter/google-breakpad/src/processor/minidump.cc:306:17: warning: an integer is interpreted as a character code when assigning it to a string; if this is intended, cast the integer to the appropriate character type; if you want a string representation, use the appropriate conversion facility
toolkit/crashreporter/google-breakpad/src/processor/minidump.cc:307:17: warning: an integer is interpreted as a character code when assigning it to a string; if this is intended, cast the integer to the appropriate character type; if you want a string representation, use the appropriate conversion facility
toolkit/crashreporter/google-breakpad/src/processor/minidump.cc:309:17: warning: an integer is interpreted as a character code when assigning it to a string; if this is intended, cast the integer to the appropriate character type; if you want a string representation, use the appropriate conversion facility
toolkit/crashreporter/google-breakpad/src/processor/minidump.cc:310:17: warning: an integer is interpreted as a character code when assigning it to a string; if this is intended, cast the integer to the appropriate character type; if you want a string representation, use the appropriate conversion facility
toolkit/crashreporter/google-breakpad/src/processor/minidump.cc:311:17: warning: an integer is interpreted as a character code when assigning it to a string; if this is intended, cast the integer to the appropriate character type; if you want a string representation, use the appropriate conversion facility
toolkit/crashreporter/google-breakpad/src/processor/minidump.cc:313:17: warning: an integer is interpreted as a character code when assigning it to a string; if this is intended, cast the integer to the appropriate character type; if you want a string representation, use the appropriate conversion facility
toolkit/crashreporter/google-breakpad/src/processor/minidump.cc:314:17: warning: an integer is interpreted as a character code when assigning it to a string; if this is intended, cast the integer to the appropriate character type; if you want a string representation, use the appropriate conversion facility
toolkit/crashreporter/google-breakpad/src/processor/minidump.cc:315:17: warning: an integer is interpreted as a character code when assigning it to a string; if this is intended, cast the integer to the appropriate character type; if you want a string representation, use the appropriate conversion facility
toolkit/crashreporter/google-breakpad/src/processor/minidump.cc:316:17: warning: an integer is interpreted as a character code when assigning it to a string; if this is intended, cast the integer to the appropriate character type; if you want a string representation, use the appropriate conversion facility
MozReview-Commit-ID: AUOyOuCzy1R
--HG--
extra : source : 93356b5c58539d19c27dade7b1514bae709bc149
extra : histedit_source : 4bc38ab5a7a50869aaf4fce87aa2f75ce9dd301a
Finds string constructors that are suspicious and probably errors. There are currently no misc-string-constructor warnings in mozilla-central!
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-string-constructor.html
MozReview-Commit-ID: LyJt6wqOhg9
--HG--
extra : source : 0b36b6b1b7931adec5846086a52080edb3ec5e7d
extra : histedit_source : 30249980b219d4813fc5503c87e84265ad354e2f
This check finds memset() calls with potential mistakes in their arguments. There are currently no bugprone-suspicious-memset-usage warnings in mozilla-central!
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-suspicious-memset-usage.html
MozReview-Commit-ID: 9gmtidgMPwW
--HG--
extra : source : 9c6f6e1553c45751f476c2d8418b9d4735e27e50
extra : histedit_source : 721536e24babf3734e116bd6beaf8d43722cca96
Check for memory leaks, double free, and use-after-free and offset problems involving malloc. There are currently no clang-analyzer-unix.Malloc warnings in mozilla-central!
https://clang-analyzer.llvm.org/available_checks.html
MozReview-Commit-ID: G32SlokD64O
--HG--
extra : source : a2c8ccd2da1968b64510569f12f4631c54fea2d8
extra : histedit_source : b42c3ce2c3f8132fc0b301e6309b5ad25192167c
Check for null pointers being passed as arguments to C string functions. There are no clang-analyzer-unix.cstring.NullArg warnings in mozilla-central!
strlen
strnlen
strcpy
strncpy
strcat
strncat
strcmp
strncmp
strcasecmp
strncasecmp
https://clang-analyzer.llvm.org/available_checks.html
MozReview-Commit-ID: EkfaItfo5cu
--HG--
extra : source : e05c6cfa3b8ae6b3234ebf5e4895475bc623edcd
extra : histedit_source : 6aa97bb8d82884fb2ac92793df9defd7a7985e89
Check the size argument passed to strncat for common erroneous patterns. There are currently no clang-analyzer-unix.cstring.BadSizeArg warnings in mozilla-central!
https://clang-analyzer.llvm.org/available_checks.html
MozReview-Commit-ID: DUI3ZNIBoLQ
--HG--
extra : source : 8dafc73215cddd2737b4d8dbcb926521736d98c2
extra : histedit_source : ed27a98e47c01c9951c03eb2129ed4997f3cf624
This check finds unused namespace alias declarations. There are currently no misc-unused-alias-decls warnings in mozilla-central!
https://clang.llvm.org/extra/clang-tidy/checks/misc-unused-alias-decls.html
MozReview-Commit-ID: LHziGESvaM5
--HG--
extra : rebase_source : f10fbb6364bc947b5fa2ca8c0b47494519856940
extra : source : 987ca732290093c4bd36690c6ebd3ed2ac0b5444
This check finds potentially swapped function arguments by looking at implicit conversions. There are currently no misc-swapped-arguments warnings in mozilla-central!
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-swapped-arguments.html
MozReview-Commit-ID: 6SETUcQhQP
--HG--
extra : rebase_source : d364fc90e776807ab2540d714594d07a5a83b054
extra : source : 689980bf12e98780d0d60c851549d16a4cc8efb0
This check finds side effects from repeated macro arguments:
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-macro-repeated-side-effects.html
There are currently 16 misc-macro-repeated-side-effects warnings in mozilla-central, but they are all in third-party gfx/cairo code:
gfx/cairo/cairo/src/cairo-tor-scan-converter.c:1432:10: warning: side effects in the 1st macro argument 'x' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:1011:16: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:1037:16: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:1062:16: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:1088:16: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:1107:16: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:1126:27: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:1194:21: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:1258:16: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:600:28: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:629:28: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:660:28: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:690:28: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:721:28: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-access.c:986:16: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
gfx/cairo/libpixman/src/pixman-edge-imp.h:126:20: warning: side effects in the 2nd macro argument 'ptr' are repeated in macro expansion
MozReview-Commit-ID: CQ6iO9JO773
--HG--
extra : rebase_source : 0e7dc6fa3990ab187c597d8042a403c554152b02
extra : source : 5f47d400d53107df0e0478b369745bfd3f055702
Check for memory leaks. Traces memory managed by new/ delete. There are currently no clang-analyzer-cplusplus.NewDeleteLeaks warnings in mozilla-central!
https://clang-analyzer.llvm.org/available_checks.html
MozReview-Commit-ID: 3tmwR26UB8K
--HG--
extra : rebase_source : 3796cc6b61c03e83ce8b390e3342b870085b2ed2
extra : source : 3389fb54d2e3daee38db38503b37e9d994878bcd
Check for double-free, use-after-free and offset problems involving C++ delete. There are currently no clang-analyzer-cplusplus.NewDelete warnings in mozilla-central!
https://clang-analyzer.llvm.org/available_checks.html
MozReview-Commit-ID: 9sVp4fc4JTj
--HG--
extra : rebase_source : 733974ff07b873f6e5cd1e83104f82eafbf7f3c7
extra : source : 778684b276e6658fb9f3fa125aaec984cca8760a
One of the big downsides to |mach try fuzzy| is that if you use the interactive
finder, there's no way to repeat your last action. If you want to run the same
push again, you have to manually re-select all the same tasks a second time.
It is possible to save presets, but this is fairly heavy-weight and (more)
permanent. Sometimes you just want to re-run a push a few times and forget
about it. It's also possible to craft the query on the command line with -q,
but then you don't get the immediate visual feedback, so you can't be sure that
you typed out the right things without actually pushing.
With |mach try again|, everytime you generate a try_task_config.json via
'fuzzy', 'empty' or any other subcommands that may exist in the future, it'll
get stored in a history file under ~/.mozbuild. Then running |mach try again|
will simply re-run the most recent try_task_config.json.
You'll also be able to view the whole history via |mach try again --list| and
select a specific try_task_config.json (i.e not the most recent one) via
|mach try again --index <index>|.
Example usage will be:
$ ./mach try fuzzy
<select a bunch of tasks>
$ ./mach try again
<re-pushes exact same set of tasks>
MozReview-Commit-ID: 3EZjVCy08uq
Depends on D1808.
Differential Revision: https://phabricator.services.mozilla.com/D1867
--HG--
extra : moz-landing-system : lando
This fixes a regression from bug 1454640 where urls had an extra 'docs' path inserted into them, e.g:
toolkit/components/telemetry/telemetry/index.html
became:
toolkit/components/telemetry/docs/telemetry/index.html
Differential Revision: https://phabricator.services.mozilla.com/D2079
--HG--
extra : histedit_source : 15c679e2f9366c1ea424adc4c82d7c184d80b3bb
This prevents accidental changes to package-lock.json when ESLint's setup runs 'npm install'.
Also revert the recent accidental changes to package-lock.json.
MozReview-Commit-ID: 21ebhOlQcMv
Differential Revision: https://phabricator.services.mozilla.com/D2118
--HG--
extra : moz-landing-system : lando
We're supposed to be linting both .py and .configure files with flake8. However
we never inform flake8 of this fact.
So e.g running:
./mach lint -l flake8 mobile/android
Will not lint mobile/android/gradle.configure. However since flake8 will run on
a file regardless of its extension if you pass that file in directly, it means
that running:
./mach lint -l flake8 mobile/android/gradle.configure
*Will* cause the file to be linted (and subsequently fail). This fix makes sure
that flake8 knows to look at .configure files in addition to .py. Since this
means many .configure files around the tree will start getting linted for the
first time, we need to exclude them until they can be fixed.
Differential Revision: https://phabricator.services.mozilla.com/D1975
--HG--
extra : moz-landing-system : lando
Added `./mach python-safety`, distinct from python-test so it doesn't have
to be run on every CI job - its errors may not depend on the area the push has changed.
Added the python/safety directory to ensure a different Pipfile is used, avoiding
conflicts with python-test.
Differential Revision: https://phabricator.services.mozilla.com/D1825
--HG--
extra : moz-landing-system : lando
Summary:
- Add explicit keyword on ProcessCount ctor
- Fix an unused variable in a loop
Reviewers: marco
Reviewed By: marco
Bug #: 1471882
Differential Revision: https://phabricator.services.mozilla.com/D1864
--HG--
extra : rebase_source : be0ae98ba0b54fc626b6857336c59d114be1e6f3
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
Currently it's possible to specify a single query and take the union of terms with the '|'
symbol. However if you want to craft anything more complicated (i.e linux mochitest and
xpcshell, but windows reftest), it becomes really difficult. This allows developers to union
the result of multiple queries.
For example:
./mach try fuzzy -q "'linux 'mochitest | 'xpschell" -q "'windows 'reftest"
Differential Revision: https://phabricator.services.mozilla.com/D1838
This includes both the vanilla sources we haven't forked and the client
sources that we have. Client patches were applied manually up to version
69c2c51dd89965d234eec16e3a9353634831916b. The following changes were not
included as they break merging segments corresponding to libxul.so in the
module list:
8915f7be39448d9257b6da3ad0233944d1d9a92a
17ad0c18b179c135fc5a3d2bba199c3fa4276035
94b6309aecaddfcf11672f6cfad9575d68ad3b40
With these changes applied two entries for libxul.so are generated, the second
one is bogus and prevents symbolication from working correctly.
The build system and some of the tools relying on breakpad were also updated
to work with the new version.
--HG--
extra : source : fe4d49307f8890a0c430c257c96f74a9552eeb31
extra : histedit_source : bc84861445bd93856cd0d0c864fd15ad7d9ccc12%2C1efd65797da46e33481afa61a302098780b0f107
It already had test files, but wasn't actually enabled. Also add a mock internal
std::string::find signature; two comments about disabled checks; and fix a typo.
This changes two config options:
pytest_classes = PyTest # only classes that start with 'PyTest' will be considered tests (previously this was Test)
xfail_strict = true # tests marked as xfail will cause pytest to return non-zero if they unexpectedly pass
MozReview-Commit-ID: DCWoDFbe6Mk
--HG--
extra : rebase_source : 9aa806e035d62d51bb338708396851c40f55ee00
* GetScriptCompartment => GetScriptRealm
* Adds IsSystemRealm in addition to IsSystemCompartment and uses it where we can.
* JS_GetCompartmentPrincipals and IsSystemCompartment now release-assert they have a single realm. This is temporary until we know what Gecko will do/need exactly.
We were using nsCString to pass the profiler data between processes. But it was
failing to send because there is a ~256MB limit for the string data. So we
changed it to use Shmem instead. Shmem creates a shared memory and passes the
weak reference. With it, we can send larger data without having a problem.
MozReview-Commit-ID: 1kj57fZDXVF
--HG--
extra : rebase_source : 25a8ab57bcae8012fee1cdd9d4b767036db192d7
This upgrades sphinx to version 1.7.5, which contained a couple backwards
incompatible changes that needed fixing.
This also leaves sphinx-js at version 2.1 as upgrading that to 2.5 seems to
introduce an intermittent in the Doc task.
MozReview-Commit-ID: FRUTcXs5yzb
--HG--
extra : rebase_source : e874a2e9c637b7cec710203f75f4dd989a5681a1
Bug 1447338 introduced the new feature for responsiveness handling, but
we forgot to include it in the default feature list. As a result it's
not included by default when profiling the startup.
MozReview-Commit-ID: 1YPcDaGZR9s
--HG--
extra : rebase_source : 421bbda28b3c7170c4dc3f676f57844483528276
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This was used to label IndexedDB work and work in storage/mozStorage*.
I don't think this deserves its own category; categories are most useful for
the main thread, and most of the time-consuming database-related work happens
on helper threads. The main thread pieces are mostly for asynchronicity-
coordination and don't usually take up time.
This patch labels IndexedDB work as DOM instead (which is maybe debatable) and
the rest as OTHER.
MozReview-Commit-ID: 3UYhFFbi3Ry
--HG--
extra : rebase_source : 5c88dfd67274103de01fe44191f49776017738f9
The next changeset is going to move over more annotations that Gecko developers
would count as "layout" into the LAYOUT category, and which is currently marked
as GRAPHICS.
We can add a subcategory for style resolution once we have subcategories, but
for now I think it makes more sense to put style resolution into the same bucket
as reflow and display list building.
MozReview-Commit-ID: 7r9eICVBA1Z
--HG--
extra : rebase_source : ce2df7a07522e99b0ccb59e40a8eae590ebfe834
This was used to label IndexedDB work and work in storage/mozStorage*.
I don't think this deserves its own category; categories are most useful for
the main thread, and most of the time-consuming database-related work happens
on helper threads. The main thread pieces are mostly for asynchronicity-
coordination and don't usually take up time.
This patch labels IndexedDB work as DOM instead (which is maybe debatable) and
the rest as OTHER.
MozReview-Commit-ID: 3UYhFFbi3Ry
--HG--
extra : rebase_source : 16abc3c4bd8ed9ac55b5c188bd10ee26b0566330
The next changeset is going to move over more annotations that Gecko developers
would count as "layout" into the LAYOUT category, and which is currently marked
as GRAPHICS.
We can add a subcategory for style resolution once we have subcategories, but
for now I think it makes more sense to put style resolution into the same bucket
as reflow and display list building.
MozReview-Commit-ID: 7r9eICVBA1Z
--HG--
extra : rebase_source : 53ce9912d3219ce8ce5dc411e03bb5ef5e2c7b64
This was used to label IndexedDB work and work in storage/mozStorage*.
I don't think this deserves its own category; categories are most useful for
the main thread, and most of the time-consuming database-related work happens
on helper threads. The main thread pieces are mostly for asynchronicity-
coordination and don't usually take up time.
This patch labels IndexedDB work as DOM instead (which is maybe debatable) and
the rest as OTHER.
MozReview-Commit-ID: 3UYhFFbi3Ry
--HG--
extra : rebase_source : f83946138d8311ea5aa91f537a1d8e420e784068
The next changeset is going to move over more annotations that Gecko developers
would count as "layout" into the LAYOUT category, and which is currently marked
as GRAPHICS.
We can add a subcategory for style resolution once we have subcategories, but
for now I think it makes more sense to put style resolution into the same bucket
as reflow and display list building.
MozReview-Commit-ID: 7r9eICVBA1Z
--HG--
extra : rebase_source : f447dcbb9d81be81a418c7464ef814ce4778073b
This was changing the project from "main" -> ("main",) which was causing the DocUp
task to upload to urls like:
"('main',)/62.0/_sources/..."
MozReview-Commit-ID: 1bL9nqiAEFE
--HG--
extra : rebase_source : 8f4148dd003dfcfb4c0ba513e4fa7e2ca540dce3
This adds autopep8 to flake8_requirements.txt. When --fix is passed in,
autopep8 will run prior to the normal flake8 run, so only errors that couldn't
be fixed automatically will be shown.
There is one caveat, namely autopep8 will only use the root .flake8 file
(there's no support for passing in subconfigs).
MozReview-Commit-ID: FJ0doey2KVb
--HG--
extra : rebase_source : 8cff7352ce0d2eb9e5d774085005043780c2e2a2
Changed DOMEventMarkerPayload to use tracing markers to be able to see unfinished
DOMEvents in the profiler. DOMEventMarkerPayload was containing both start and
end timestamps and we were adding it once DOMEvent finishes. Now, we are adding
two tracing markers. Once the event starts and once the event ends. That makes the
start of the event visible on the profiler.
MozReview-Commit-ID: Gak6dGsgMDt
--HG--
extra : rebase_source : 6d2c9930964503a4865b92d85a0437e33acf8dc7
Also bump eslint-plugin-mozilla version to 0.13.0
MozReview-Commit-ID: ELWC6RYNPjT
--HG--
extra : rebase_source : aecc1a032e761812f78f9e57a2534d0e694d0b9c