Also bump eslint-plugin-mozilla version to 0.13.0
MozReview-Commit-ID: ELWC6RYNPjT
--HG--
extra : rebase_source : aecc1a032e761812f78f9e57a2534d0e694d0b9c
To collect extension metadata, we need to get an ExtensionPolicyService singleton,
but during shutdown, we are deleting the ExtensionPolicyService instance and then
trying to collect extension metadata. Since collecting extension metadata for
profiler requires ExtensionPolicyService, we have to create it again. But we
cannot create it while XPCOM shutting down. Therefore, we had to skip collecting
extension metadata.
MozReview-Commit-ID: AR544ILhSBT
--HG--
extra : rebase_source : 4e9e83665f12cf6d7bc886e7fbcb5b4178b17ab5
This also changes many references to the 'pseudo stack' to refer to the 'label
stack' instead. The label stack is one of the two stacks that are managed by
the profiling stack, the other stack being the JS interpreter stack.
MozReview-Commit-ID: Ed0YMMeCBY8
--HG--
extra : rebase_source : 5675d670f424c7d7dda04bafc2b3431fa2485e3c
The term "entry" is already used for elements in the profile buffer.
MozReview-Commit-ID: 1aB22V6veQh
--HG--
extra : rebase_source : c664eb4d6bed6cb74ba8a1b67ea99bd8ca57bcf7
extra : source : 3264c0cc0027b240b55bd3aebf27263b1e1d1cc0
The name Cpp was confusing, because C++ functions are in the native stack, not
in the pseudo stack. The pseudo stack only contains frames for manually
instrumented code that uses AutoProfilerLabel, and JS frames.
MozReview-Commit-ID: 9ptfhREo0qy
--HG--
extra : rebase_source : 76a1a32acb4c946aeb2ad45e904e419c1c9e2ad1
We no longer store the docs under a project name (since all the docs are now
built using the root conf.py). This mean the name and version are only used for
packaging and uploading, which typically is only used in CI.
This allows us to lazy load the package name and version, so we only read the
conf.py when we need to.
MozReview-Commit-ID: DV5Jxrbskoh
--HG--
extra : source : d03f75986f626938142bd5bde293773506a2fc14
extra : amend_source : d6d0ff5673515cac3a6c7cf03bfce4ffcd09991f
Previously, running |mach doc <subtree>| would use whatever conf.py file
happened to live in the subtree. For example, running:
./mach doc tools/lint
Would build with tools/lint/docs/conf.py. This is bad because it means the
generated docs will look different from the docs that eventually will be
published to firefox-source-docs.mozilla.com.
This patch makes sure we always use tools/docs/conf.py for building, even when
only generating a subtree.
Furthermore, this sets things up such that when you modify a file, only the
subtree containing the modified file will be re-generated. This cuts down
rebuild times from ~2 minutes to ~20 seconds.
There is one caveat. When rebuilding a subtree, the index of other trees will
be overwritten in that particular subtree. I couldn't figure out anyway around
this. This tradeoff for *much* faster rebuild times seems worth it.
MozReview-Commit-ID: Ly88mvHKpo7
--HG--
extra : source : 47fc3e2238676a40a3adc84239baed1ce873e95e
The current mechanism for reading SPHINX variables assumes we always want to
read metadata for the entire tree. Now that we have the ability to rebuild
specific subtrees, this assumption is false.
This patch allows us to specify a path that find_sphinx_variables can use to
filter down the set of moz.build variables it will traverse, yielding only
moz.builds that could potentially impact the specified path.
MozReview-Commit-ID: ALrCFLFgMLH
--HG--
extra : source : 22f2dc60e6d859d3ca411826c77002d87c1a49bd
Now that we can rebuild docs with the liveserver, there are some optimizations
we should make. One of those is processing the sphinx moz.build variables. This
patch makes sure we don't re-process moz.build if we've already done so in a
previous rebuild.
MozReview-Commit-ID: 2AIr1KeAPQV
--HG--
extra : source : 30b4083534b51213a1b9fe0d86f996cfa0e7fa54
In the mozbuild.sphinx extension, we create a new SphinxManager instance each
time. However this isn't ideal now that we can rebuild the docs within the same
interpreter using the livereload server.
This makes use of a singleton so that we can share state not only between
multiple invocations of sphinx-build, but also with the mach command. This will
be taken advantage of more heavily in future commits in this series.
MozReview-Commit-ID: 7ERYeN5BPeI
--HG--
extra : source : 8309212d820bcca29aa95b7892d39940437f2aa8
These two functions are typically only used by CI for packaging/uploading the
documentation. This is a minor re-organiztion for clarity.
MozReview-Commit-ID: 62UhQhSSkOs
--HG--
extra : source : 9942d2df371989c5dd67a75fd7a695533141dd89
We no longer store the docs under a project name (since all the docs are now
built using the root conf.py). This mean the name and version are only used for
packaging and uploading, which typically is only used in CI.
This allows us to lazy load the package name and version, so we only read the
conf.py when we need to.
MozReview-Commit-ID: DV5Jxrbskoh
--HG--
extra : rebase_source : d227b8a800715c677602cbbc9b868df5dbd31131
Previously, running |mach doc <subtree>| would use whatever conf.py file
happened to live in the subtree. For example, running:
./mach doc tools/lint
Would build with tools/lint/docs/conf.py. This is bad because it means the
generated docs will look different from the docs that eventually will be
published to firefox-source-docs.mozilla.com.
This patch makes sure we always use tools/docs/conf.py for building, even when
only generating a subtree.
Furthermore, this sets things up such that when you modify a file, only the
subtree containing the modified file will be re-generated. This cuts down
rebuild times from ~2 minutes to ~20 seconds.
There is one caveat. When rebuilding a subtree, the index of other trees will
be overwritten in that particular subtree. I couldn't figure out anyway around
this. This tradeoff for *much* faster rebuild times seems worth it.
MozReview-Commit-ID: Ly88mvHKpo7
--HG--
extra : rebase_source : 379ffb482a4d15f5f6b394f93adab2b536c7ce00
The current mechanism for reading SPHINX variables assumes we always want to
read metadata for the entire tree. Now that we have the ability to rebuild
specific subtrees, this assumption is false.
This patch allows us to specify a path that find_sphinx_variables can use to
filter down the set of moz.build variables it will traverse, yielding only
moz.builds that could potentially impact the specified path.
MozReview-Commit-ID: ALrCFLFgMLH
--HG--
extra : rebase_source : d0c26a006bb4dbc429be5eedad7825d4412dc2a4
Now that we can rebuild docs with the liveserver, there are some optimizations
we should make. One of those is processing the sphinx moz.build variables. This
patch makes sure we don't re-process moz.build if we've already done so in a
previous rebuild.
MozReview-Commit-ID: 2AIr1KeAPQV
--HG--
extra : rebase_source : d8034ef5be416975c19a473d5a13f073e95aba80
In the mozbuild.sphinx extension, we create a new SphinxManager instance each
time. However this isn't ideal now that we can rebuild the docs within the same
interpreter using the livereload server.
This makes use of a singleton so that we can share state not only between
multiple invocations of sphinx-build, but also with the mach command. This will
be taken advantage of more heavily in future commits in this series.
MozReview-Commit-ID: 7ERYeN5BPeI
--HG--
extra : rebase_source : 44aee637ea9b828b43b82e8639ddc3cc7f68c797
These two functions are typically only used by CI for packaging/uploading the
documentation. This is a minor re-organiztion for clarity.
MozReview-Commit-ID: 62UhQhSSkOs
--HG--
extra : rebase_source : c5b800734041689453f965e50ce356c2e7a623d2
Also fixes existing code which fails the rule.
MozReview-Commit-ID: CkLFgsspGMU
--HG--
extra : rebase_source : 86a43837659aa2ad83a87eab53b7aa8d39ccf55b
Also use package-lock.json rather than npm-shrinkwrap.json as we no longer need to support the latter.
MozReview-Commit-ID: 4yaFcElvhF7
--HG--
rename : npm-shrinkwrap.json => package-lock.json
extra : rebase_source : ae6fcadd8b4a5213fb94cd6426909c2efebfb6a1
For some reason, GNU as is not happy with the assembly generated after
bug 1238661 anymore on Debian armel.
OTOH, as mentioned in bug 1238661 comment 4, we actually don't need this
workaround anymore, so let's just kill it.
--HG--
extra : rebase_source : 6fd06832136d4f840c65f74b63f1c1bec48d525d
LUL::mAdminThreadId is used only to assert that certain calls into the LUL
object are made on the correct thread. Because those assertions are done
using MOZ_ASSERT, some compilers spot that LUL::mAdminThreadId is unused in
non-debug builds, emit a warning to that effect, and then cause the build to
fail due to the presence of -Werror.
Given that (1) it's unlikely that people will use the profiler in debug
builds, (2) failure of these assertions is likely to lead to deadlocking or
crashing in the profiler, and (3) they don't occur on high-frequency paths,
a good solution seems to be to convert them to MOZ_RELEASE_ASSERTs, hence
causing LUL::mAdminThreadId to be used in even in non-debug builds.
In some cases, related MOZ_ASSERTs relating to LUL::mAdminMode have also
been upgraded to MOZ_RELEASE_ASSERTs, for consistency with the
LUL::mAdminThreadId changes.
--HG--
extra : rebase_source : 554a31060a828db01246ece6d1e3afbcc0b42cd2
Since aarch64's DWARF doesn't have pc register, I use x29 (link register) if
not first frame.
I test by gtest on Linux/aarch64, and profiler works on Android/aarch64.
EM_AARCH64 might not be defined on our builders since headers are old, so
this define is needed.
MozReview-Commit-ID: 8VDb5i0vwBT
--HG--
extra : rebase_source : abfe58624dabc2551deb03527db4be3b93490206
This has the effect of exposing explicit imports (e.g., defineModuleGetter),
but not implicit imports (e.g., Cu.import), to rules like no-unused-vars and
no-shadow.
MozReview-Commit-ID: C8oXoSKMU1s
--HG--
extra : rebase_source : 21e87b48514c2075d09eca7e20a1671b206d871f
extra : histedit_source : 5080aef443f0a21f3a1e3e2bb398aadcc5a05402%2Cc472717700446079b1f7ac552a4c3339d207ad61
This file is not part of the build. (it's used to generate
generated-mochitest.ini)
What's tripping up this lint is this line:
# [gl:0D6DE000] mozilla::gl::GLContext::raw_fDrawArrays: Generated unexpected GL_INVALID_OPERATION error. (0x0502)
This line is picked up as a false-positive, since the too-naive regex
(effectively /#.*\[/) interprets this as a skipped test.
MozReview-Commit-ID: 2bMIkCH8WK9
Going through XPConnect for JS-to-JS access in the blocklist service adds no
benefit, but does add a lot of overhead and maintenance burden.
MozReview-Commit-ID: Lf1mDK0b0B0
--HG--
extra : rebase_source : 410ed3fcf999d7c7775ef4926c89f67d9e342da8
This changes the default to opening a livereload webserver after doc generation
(as opposed to opening the index file). Any changes to the specified path will
result in a rebuild and refresh of the browser.
For example, if you run:
./mach doc tools/lint
The linting docs will be built, served and opened in a browser. Modifying any
file under 'tools/lint/docs' will refresh the browser with your changes.
To disable this behaviour and simply open the index file, you can pass in
'--no-serve'. The '--no-open' flag will continue to work (both with http and
the file system).
One caveat to this patch is that when generating the root docs (by running
|mach doc|), we don't watch all possible doc paths (just the root one under
'tools/docs/'). This will probably be fixed in the follow-up bug 1454640.
MozReview-Commit-ID: FQecuePM0zZ
--HG--
extra : rebase_source : 3240402d7505e99a4f64dada309b1baec78306e1
This removes the ability to specify multiple doc paths at the same time with
|mach doc|. We will be changing the default from opening index files to serving
the documentation with a webserver. Supporting multiple doc roots would mean
spinning up multiple servers in different threads.
This would add a lot of complexity for a feature which I don't think is very
useful. It's very rare that one would need to edit more than one doc location
at the same time. And if this is ever needed, the developer can just build the
entire doctree (by running |mach doc|) or run |mach doc <path>| in multiple
different terminals.
MozReview-Commit-ID: GXEZJSgLpgF
--HG--
extra : rebase_source : 2eda23274eb6c2be82f7e77ca577072386bada34
Some requirements.txt are very large and result in a lot of package already
installed messages. Would be nice to hide this.
MozReview-Commit-ID: FQecuePM0zZ
--HG--
extra : rebase_source : 58eaa7324775cfaa39077871be0be0ef39ad7c11