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
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