The shims that this rule tests for no longer exist.
MozReview-Commit-ID: DMgP7Hczavc
--HG--
extra : rebase_source : 765ddd5c62c9449c07ed050e44d86a3bd5c0ae64
extra : amend_source : 627a7694ac07182200f876901ded7a34721cd228
There a few pieces needed here to properly handle KeyboardInterrupts.
1. All in-progress work needs to abort. Ideally the underlying linters will be
able to catch KeyboardInterrupt, and return partial results (like the flake8
linter does). Linters may alternatively allow the KeyboardInterrupt to
propagate up. Mozlint will catch and handle this appropriately, though any
results found will be lost. The only change to this behaviour was fixing a bug
in the flake8 linter.
2. Any unstarted jobs need to be canceled. In concurrent.futures, there are two
different queues. First, jobs are placed on the work queue, which is just a list
maintained by the parent process. As workers become available, jobs are moved
off the work queue, and onto the call queue (which is a multiprocessing.Queue).
Jobs that live on the work queue can be canceled with 'future.cancel()', whereas
jobs that live on the call queue cannot. The number of extra jobs that are stored
on the call queue is determined by this variable:
https://hg.mozilla.org/mozilla-central/file/deb7714a7bcd/third_party/python/futures/concurrent/futures/process.py#l86
In this patch, the parent process' sigint handler (which will be called on Ctrl-C)
is responsible for canceling all the jobs on the work queue. For the jobs on the
call queue, the best we can do is set a global variable that tells workers to
abort early.
3. Idle workers should exit gracefully. When there are no more jobs left, workers
will block on the call queue (either waiting for more jobs, or waiting for the
executor to send the shutdown signal). If a KeyboardInterrupt is received while a
worker is blocking, it isn't possible to intercept that anywhere (due to quirks
of how concurrent.futures is implemented). The InterruptableQueue class was
created to solve this problem. It will return None instead of propagating
KeyboardInterrupt. A None value will wake the worker up and tell it to gracefully
shutdown. This way, we avoid cryptic tracebacks in the output.
With all of these various pieces solved, pressing Ctrl-C appears to always exit
gracefully, sometimes even printing partial results.
MozReview-Commit-ID: 36Pe3bbUKmk
--HG--
extra : rebase_source : d4c312ee5cc3679eeee1407c5521aed679f84ad4
extra : source : a93a00141bf62f6bc9e30934c0e56f6b2e434bf0
Thunderbird is currently still building on macOS, where `mktemp` requires an
argument.
MozReview-Commit-ID: DCoZAYA6tTI
--HG--
extra : rebase_source : 48775eba4f934fd244a74da615bc7754370b504e
The overlay was responsible for script loading and defining three elements
(bhTooltip, placesCommands, placesContext). In the majority of places where
the overlay was included only part of it was used. To remove the overlay, the
elements were each split into include files and moved into where they
were used. For the scripts, a JS file was added that defines all the lazy
modules and then this script, globalOverlay.js and utilityOverlay.js were
inlined to everywhere that would have included them from the overlay.
MozReview-Commit-ID: 8T5D46oYWLn
--HG--
rename : browser/components/places/content/placesOverlay.xul => browser/components/places/content/placesCommands.inc.xul
rename : browser/components/places/content/placesOverlay.xul => browser/components/places/content/placesContextMenu.inc.xul
extra : rebase_source : c1071af4ea264a95183cbc65caae98feb23d58e5
Move the main contents of editBookmarkOverlay.xul into an include file and
inline the DTD and CSS files where used. Convert several chrome tests to
browser tests since the preprocessor is hard to use within the testing
framework.
MozReview-Commit-ID: DpPBOpZSuBN
--HG--
rename : browser/components/places/content/editBookmarkOverlay.js => browser/components/places/content/editBookmark.js
rename : browser/components/places/content/editBookmarkOverlay.xul => browser/components/places/content/editBookmarkPanel.inc.xul
rename : browser/components/places/tests/chrome/test_bug427633_no_newfolder_if_noip.xul => browser/components/places/tests/browser/browser_bug427633_no_newfolder_if_noip.js
rename : browser/components/places/tests/chrome/test_bug485100-change-case-loses-tag.xul => browser/components/places/tests/browser/browser_bug485100-change-case-loses-tag.js
rename : browser/components/places/tests/chrome/test_bug631374_tags_selector_scroll.xul => browser/components/places/tests/browser/browser_bug631374_tags_selector_scroll.js
rename : browser/components/places/tests/chrome/test_editBookmarkOverlay_keywords.xul => browser/components/places/tests/browser/browser_editBookmark_keywords.js
rename : browser/components/places/tests/chrome/test_editBookmarkOverlay_tags_liveUpdate.xul => browser/components/places/tests/browser/browser_editBookmark_tags_liveUpdate.js
rename : browser/themes/linux/places/editBookmarkOverlay.css => browser/themes/linux/places/editBookmark.css
rename : browser/themes/osx/places/editBookmarkOverlay.css => browser/themes/osx/places/editBookmark.css
rename : browser/themes/windows/places/editBookmarkOverlay.css => browser/themes/windows/places/editBookmark.css
extra : rebase_source : aca072691251c1a44e82ab8091796abd2b140e22
MinGW headers are all lowercase, and because we build FF with MinGW
on Linux - capitalization matters. But if you're plugging along,
working on Windows, you might forget about that, and wind up
inadvertently breaking the MinGW build because you capitalized
an include file (as is common in Windows development.)
This lint job takes the list of header files from MinGW
(generated by cd mingw-w64/mingw-w64-headers &&
find . -name "*.h" | xargs -I bob -- basename bob | sort | uniq)
and will alert if they are in an #include statement but not
all-lowercase.
MozReview-Commit-ID: 4QFSdHx5Uak
--HG--
extra : rebase_source : d76c258191d4cbb7665775bd1b8d79028890727f
console.assert keeps the same semantics as NS_ASSERT in that it doesn't throw an exception,
but a lot of the places code was using it in a way that would be better served by throwing
an exception when the condition is false.
MozReview-Commit-ID: DEF5HSfYO36
This changeset changes behavior.
If the profile is streamed before any JSContext has gone away, we now iterate
over the entire buffer twice (per thread): First, to collect information about
JIT frames, and then again when we build the JSON for the samples. The first
traversal stores small pieces of JSON for JIT fromes in individual strings, and
the second iteration splices those strings into the thread JSON's frame table.
When the JSContext for a thread goes away, we no longer build JSON for samples,
and we don't reset the profiler buffer. We now only build the JSON for JIT
frames. Once the complete profile is requested and we build samples for it, we
iterate over the entire buffer, and look up the cached JIT frame information for
JitReturnAddr entries from the correct range. Different parts of the buffer may
correspond to the life time of different JSContexts: For each JSContext we will
have one range in the JITFrameInfo, and we can look up the correct range based
on the buffer position of the JitReturnAddr entry that we're processing.
This new way of doing things has multiple advantages:
- We no longer reset the buffer, so we no longer lose information about other
threads.
- All threads from a given process now always have sample data for the same
time range. Before this change, the "partial profile" from a thread that
lost its JSContext could extend further into the past than the other threads'
profiles.
- Requesting profiles multiple times now has more consistent results. Before
this change, the first requested profile would include the partial profile,
but then the partial profile was discarded. And the second requested profile
would not contain any data for the time before the JSContext went away.
- We now do less work when a thread's JSContext goes away. This should
decrease the interruption time.
MozReview-Commit-ID: 3KhnPtBijna
--HG--
extra : rebase_source : 2ef5ac933e4db1c98526a2b36147ff031893de9e
extra : intermediate-source : d63b04327077d1ef55f509b365cd2693905b0733
extra : source : f2d8c993aa2c16bc491c55179d545f5a2c727391
In an upcoming patch we'll want to initialize mUniqueStrings by stealing
another object's UniqueJSONStrings, but UniqueJSONStrings itself is not
move-constructible. But UniquePtr is.
Making UniqueJSONStrings itself move-constructible would be a bit tricky
because it has a SpliceableChunkedJSONWriter which is not move-constructible;
and making SpliceableChunkedJSONWriter move-constructible is hard because
there's no obvious "empty but valid" state that we could leave a moved-out-of
SpliceableChunkedJSONWriter in; for example, it expects to have a non-null
WriteFunc at all times.
MozReview-Commit-ID: Q6o61HFTiD
--HG--
extra : rebase_source : e1073be9892cf7cfd6ca4f2562ce939690b3b4d7
This also renames FlushSamplesAndMarkers to NotifyAboutToLoseJSContext.
MozReview-Commit-ID: FWinMi85yDZ
--HG--
extra : rebase_source : 6d8bfd6937ce757108f80f43e878a2dbead318bd
This makes it clear which combinations of fields are possible.
MozReview-Commit-ID: C3PriO7nWsJ
--HG--
extra : rebase_source : 68df01f11121b09b2f2762581dc28184262abfb8
I think this file was picking up such a declaration from a different file
already, through unified builds.
MozReview-Commit-ID: 9xTB2QA86U0
--HG--
extra : rebase_source : d7b614524ebdf25a185698b6632d6f925ce08da8
nsCString is the idiomatic string class we want to use anyway. There's no need
to think about std::string here.
MozReview-Commit-ID: 1rjZAyqp13d
--HG--
extra : rebase_source : 92c4eb22876c4fc89f00104c56f92a75053284e9
Bogdan Tara
Kris Maglione
Gurzau Raul
Sylvestre Ledru
Sebastian Hengst
Andrew Halberstadt
Tom Prince
Kit Cambridge
Brendan Dahl
Xidorn Quan
Tom Ritter
Narcis Beleuzu
manikishan
Greg Tatum
Edouard Oger
Daniel Marshall
Mark Banner
shindli
Markus Stange