Virtual function declarations should specify only one of `virtual`, `final`, or `override`, as per the Mozilla C++ style guide:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style
This lint warns about:
virtual void Bad1() final
void Bad2() final override
void Bad3() override final
Caveats: This lint doesn't warn about `virtual void NotBad() override` at this time because there are 8000+ instances. It also doesn't warn about function declarations that span multiple lines because the regex can't match across line breaks.
MozReview-Commit-ID: LcBsOAKKgz7
--HG--
extra : rebase_source : 4da72ffac59acdc9796e3f540f24bb97af989cd0
The file copies and renames make this patch look a bit confusing. Here's what
happens:
ThreadInfo.h:
Most of the code gets moved into RegisteredThread.h and ProfiledThreadData.h,
but a small piece remains in ThreadInfo.h.
ThreadInfo.cpp:
Gets split into RegisteredThread.cpp and ProfiledThreadData.cpp.
ThreadInfo.cpp itself goes away.
In the mercurial changeset, I've marked ThreadInfo.h as being copied to both
RegisteredThread.h and to ProfiledThreadData.h, and ThreadInfo.cpp as being
copied to RegisteredThread.cpp and as being renamed to ProfiledThreadData.cpp.
MozReview-Commit-ID: 1j1imAv9cTd
--HG--
rename : tools/profiler/core/ThreadInfo.cpp => tools/profiler/core/ProfiledThreadData.cpp
rename : tools/profiler/core/ThreadInfo.h => tools/profiler/core/ProfiledThreadData.h
rename : tools/profiler/core/ThreadInfo.cpp => tools/profiler/core/RegisteredThread.cpp
rename : tools/profiler/core/ThreadInfo.h => tools/profiler/core/RegisteredThread.h
extra : rebase_source : 91310691d5e46246ec03305511c1b86ab458b0b9
The end goal here is to be able to use |mach try fuzzy <path>| with tests that
belong to a subsuite. To do this, we need a unique 'task_regex' value for each
subsuite so that we can map a test path back to a set of tasks.
This removes the TEST_FLAVORS dict (which was mostly just a redefinition of the
data in TEST_SUITES), and instead provides two new private mappings:
<flavor> -> suite definition
(<flavor>, <subsuite>) -> suite definition
To retrieve a suite definition given a flavor/subsuite, consumers can now call
get_suite_definition.
MozReview-Commit-ID: 2pe1v1IHUVy
--HG--
extra : rebase_source : 6fff947ba214112ccf16c894174a6a0e2487111a
This fixes a bug which can happen when the default version of python differs from
the version of python used with mach.
For example, mach explicitly looks for python2.7. This means running |mach lint -l flake8|
should also run flake8 with version 2.7. But if the default is python3, and flake8 is also
installed there, the subprocess call that invokes flake8 will run under python3. This can
lead to errors like "undefined name 'basestring'" and other 2to3 gotchas.
This patch ensures that we run the flake8 binary (and the pip for installing flake8) from
the same interpreter as mach, no matter the system default.
MozReview-Commit-ID: HSuMzDsAvsW
--HG--
extra : rebase_source : faf4c8c0eb6f46d8b50c2d9be9aa6f6d47e4e0cb
This resolves the bug where we attempted to find information about JitReturnAddr
entries which were collected with a new JSContext by asking an old JSContext.
MozReview-Commit-ID: FQrnAuwwzHU
--HG--
extra : rebase_source : d0a0c7077199dc177123bb54951f4f7238c5eaf6
This makes the JSON serialization code for optimization type info a little
easier to read.
MozReview-Commit-ID: 2auHVmp7hKw
--HG--
extra : rebase_source : 1fbcf4dc63a24822f5411a7107af0e07a703a4bf
This moves the meat of the processing from operator() into the lambda, so that
it can be read in the function that calls forEachOptimizationAttempt. Now the
person who wants to understand this code hopefully won't need to scroll up and
down as much.
MozReview-Commit-ID: H9zRf1Vbswg
--HG--
extra : rebase_source : a742fa4c076437c7af6837280f725ee4532cbf2c
This may seem like an unnecessary increase in complexity, and it probably is.
But it makes it easier to reason about lifetimes if your mind is accustomed to
Rust, which would enforce a similar solution.
MozReview-Commit-ID: kJZifbjCSU
--HG--
extra : rebase_source : a2906eb296975ca689c2c3a019c33062ba17b0f2
WriteSamples doesn't really need the ability to write strings, but always passing
a string table means that there's one less thing to worry about (one less piece of
unsafe API).
MozReview-Commit-ID: 386OEibyush
--HG--
extra : rebase_source : 4fa6428b6371cf4c3db5ad77aac06c0113b2e541
I wasn't comfortable with how Stack had a reference to the UniqueStacks object.
Now we compute new the new stack index after appending a frame by explicitly
calling a method of the UniqueStacks object.
MozReview-Commit-ID: KQAI9JNb4ag
--HG--
extra : rebase_source : 5d4c7a3f637f8e2bbd4e84c3aca65290a731a206
This also renames ForEachProfiledFrameOp::FrameHandle to ProfiledFrameHandle.
MozReview-Commit-ID: 7Jh1x2QWjXe
--HG--
extra : rebase_source : 8bb0fa15fa20215f03148cfd30ae0e41f82330fd
Previously we weren't explicitly installing sphinx. Instead, the 'sphinx-js'
package had a dependency on 'sphinx<2.0'. This caused errors when sphinx
released their backwards incompatible version 1.7.
This patch pins sphinx==1.6.7 and adds all other dependencies to the same
requirements.txt (with hashes).
Upgrading to sphinx==1.7 will happen in a follow-up.
MozReview-Commit-ID: 28fKI7T4vfa
--HG--
extra : rebase_source : a9f276586ed08f49c1a26088aae88c363a31c167
This gets the pseudostack from the JSContext instead of using TLS, and only
pushes a pseudo stack frame if the profiler is active.
MozReview-Commit-ID: IzT4py9H8su
--HG--
extra : rebase_source : 9962455d59e3f8b85a347f4203ac619e654fcb7c
extra : source : f15e6874f6c14f7a5e5b0cb63acd0a95ad34db4e
This patch makes a few changes around error handling:
1) Prints the name of the linter that produced non-json output
2) Changes the 'python not found' error to a warning (as this is not fatal)
3) Makes sure said warning only gets printed once (by moving it to the setup function)
MozReview-Commit-ID: Dkq7CulTs91
--HG--
extra : rebase_source : 5d4bd32a62264a88520c09420f5acd90edcdc740
As the eslintvalidate linters haven't been doing anything but printing
an error message for a month, this is just cleanup.
MozReview-Commit-ID: 5dhrSmEv0Gi
--HG--
extra : rebase_source : 30e588f47a69b152f72d29e6aaab7efbd59fbf09
This fixes a bug which can happen when the default version of python differs from
the version of python used with mach.
For example, mach explicitly looks for python2.7. This means running |mach lint -l flake8|
should also run flake8 with version 2.7. But if the default is python3, and flake8 is also
installed there, the subprocess call that invokes flake8 will run under python3. This can
lead to errors like "undefined name 'basestring'" and other 2to3 gotchas.
This patch ensures that we run:
python2.7 -m flake8
which explicitly runs flake8 against the same interpreter as mach, no matter the default.
MozReview-Commit-ID: HSuMzDsAvsW
--HG--
extra : rebase_source : d39f97ed0f82f4d2c81f044ef1f7dad0953a3d8d
We extract some common framework to run profiler tests.
MozReview-Commit-ID: 7FPcH1NpJ7S
--HG--
extra : rebase_source : a487cb34c50889112eaecc8a20553365cfb70cfa
In this patch we also expose a script's compartment in jsfriendapi.h
MozReview-Commit-ID: LgoN8ANLgxI
--HG--
extra : rebase_source : a9a29e538041ac574b6b44fab166a7838fce54ac
Also, remove a now-obsolete comment from placesOverlay.xul and remove
some now-empty XPCShell test head files.
MozReview-Commit-ID: 6kKVQu8FAL3
--HG--
extra : rebase_source : 7dd05818d68a15bd170af734078db4ba45029d80
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
We extract some common framework to run profiler tests.
MozReview-Commit-ID: 7ct5RMhwmOe
--HG--
extra : rebase_source : 01165c506a4325310c23c9be6de2f5e6f958cf00
In this patch we also expose a script's compartment in jsfriendapi.h
MozReview-Commit-ID: JGTLygZ6DK5
--HG--
extra : rebase_source : 585edbdbc74044f2d644f5046513786ee4f42a2f
This allows linters to define a 'setup' method which will automatically be
called by |mach lint| before running the linter. Users can also explicitly run
these methods (without doing any actual linting) by running |mach lint --setup|.
MozReview-Commit-ID: 74aY1pfsaX1
--HG--
extra : rebase_source : e6a7d769ba14c996c7a77316928063fa46358c5a
This is ancient and the team that used it (gfx) is no longer using it.
MozReview-Commit-ID: HrDgmAU9QeW
--HG--
extra : rebase_source : c4a64965c4ae1a50888893e881a6e8a9688a58b6
This is a new issue that gets linted with flake8 3.5.0. Basically you should
never use a blank except: statement.
This will catch all exceptions, including KeyboardInterrupt and SystemExit
(which is likely not intended). If a catch all is needed, use
`except: Exception`. If you *really* mean to also catch KeyboardInterrupt et
al, use `except: BaseException`.
Of course, being specific is often better than a catch all.
MozReview-Commit-ID: FKx80MLO4RN
--HG--
extra : rebase_source : 7c74a7d0d81f2c984b47aff3a0ee3448b791177b
The flake8 linter requires a specific version of flake8, so that running it
locally vs in CI vs in mozreview will all produce the same results.
Allowing consumers to specify a custom flake8 binary via the FLAKE8 environment
variable, subverts that goal and can result in unexplained errors showing up in
some configurations but not others.
MozReview-Commit-ID: 1s0nC8ZO6Qi
--HG--
extra : rebase_source : f3913e2bce7770edf8deba18890f063975ca0844
Modern NDK headers all have <link.h>, so we should always include it,
and still provide shims for anything we need that's not defined in
<link.h>.
MozReview-Commit-ID: GNBDIe73RFm
--HG--
extra : rebase_source : 1246dce8a7ad201cf4f01de8e4912217636f1fc8