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
The overlay elements with children of editMenuOverlay.xul are moved into
include files (editMenuCommands.inc.xul and editMenuKeys.inc.xul). For
the other single elements in the overlay, the attributes are inlined
wherever they are used.
MozReview-Commit-ID: 792cuzUvQxT
--HG--
extra : rebase_source : 58e4c05bde16cee873d37c6198de102d048499c2
As of Bug 1425463 it's available in all contexts (including JSM). The following
patche is going to remove imports to Console.jsm, so prepare for this by allowing
it to be used as a global in eslint.
MozReview-Commit-ID: 3gCIspnlVgB
--HG--
extra : rebase_source : 6da75d42d7d937b628ef1d9c0d4e349fd76eda36
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
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 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
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 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
Tom Ritter
Sylvestre Ledru
Narcis Beleuzu
manikishan
Edouard Oger
Daniel Marshall
Mark Banner
shindli
Marco Bonardo
Sebastian Hengst
Brendan Dahl
Brian Grinstead
Andreea Pavel
Peter Van der Beken
Simon Fraser
Mark Hammond
Ciure Andrei
Kit Cambridge
Chris Peterson
Jared Wein
Andrew Halberstadt
Kyle Machulis
Noemi Erli
Gurzau Raul