Not quite sure why this dependency ever existed. These builds never use clang-tidy,
so this dependency was probably never needed in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D6493
--HG--
extra : moz-landing-system : lando
A C++ object that is exposed to JS can have its reflector used as a
key in a weak map. Because a weak map does not keep its keys alive,
this means that the reflector can be discarded if it has no other
references aside from the C++ object, which will in turn remove its
weak map entry. If the C++ object can be accessed again later from JS,
it will get a new reflector which will have no weak map entry. This is
bad because it means some internal implementation detail has resulted
in data loss that is visible to JS. (Side note: this is also an issue
for cross compartment wrappers, which is handled by another
mechanism.)
To fix this, we can preserve the wrapper of any DOM reflector used as
a weak map key. This ensures that the reflector and its C++ object
have the same lifetime. If a WebIDL object is not wrapper cached, that
means that it cannot be accessed via C++, so we don't need to preserve
the wrapper. This is currently implemented for nsISupports classes,
but not other classes. For non-nsISupports classes, it would throw an
error rather than silently fail.
My patch adds support for non-nsISupports cycle collected objects. It
turns out that the existing addProperty hook just does wrapper
preservation, so we just call it for cycle collected classes. This
does mean that if addProperty changes in the future to do something
else, this code will need to be changed.
I verified that this test fails if TryPreserveWrapper is changed to do
nothing besides return true in the non-nsISuports case.
Depends on D6197
Differential Revision: https://phabricator.services.mozilla.com/D6198
--HG--
extra : moz-landing-system : lando
The patch in the next part will need a handle to the object in
TryPreserveWrapper.
Differential Revision: https://phabricator.services.mozilla.com/D6197
--HG--
extra : moz-landing-system : lando
This makes things more explicit. Previously we were relying on those magic
global "linters" variables, and it turned out that one of the tests was
actually linting a completely different set of linters than I was expecting.
This changes things so each test needs to explicitly define which linters it
wants to use.
Depends on D6410
Differential Revision: https://phabricator.services.mozilla.com/D6412
--HG--
extra : moz-landing-system : lando
This makes this test match all the other tests (which are named after the module
they are testing).
Also rename the test function to 'test_filterpaths'.
Differential Revision: https://phabricator.services.mozilla.com/D6410
--HG--
rename : python/mozlint/test/test_filterpaths.py => python/mozlint/test/test_pathutils.py
extra : moz-landing-system : lando
This patch gets us building an updater binary that always embeds the dep certificates (instead of release or nightly), and builds a new tests package that includes it.
This was originally D5900, but that was backed out due to busting artifact builds. I've fixed that by removing the Makefile that Ted pointed out is unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D6418
--HG--
extra : moz-landing-system : lando
It's linked as part of gkrust, so this is just wasted work, and compiling it as
two different target just makes rustc do more and probably not so good work.
Differential Revision: https://phabricator.services.mozilla.com/D6487
--HG--
extra : moz-landing-system : lando
TPS is currently depending on mozrunner v7.0.1, which depends on an earlier version of mozprofile. For TPS to be able to use the latest version of mozprofile we need to release a new version of mozrunner with the recent mozprofile version identifier update.
Differential Revision: https://phabricator.services.mozilla.com/D6406
--HG--
extra : moz-landing-system : lando
As explained in the bug, it has been difficult ot find reliable STR for
the diagnostic assert, and it has been impacting the stability and usability
of Nightly builds.
Differential Revision: https://phabricator.services.mozilla.com/D6518
--HG--
extra : moz-landing-system : lando
It's possible to trigger this assertion with asyncPaint = true and
bufferRotation != (0, 0). In this case though everything should work fine,
because we didn't start a new paint task, and we should be able to copy over
buffers. So we should be able to remove this assertion.
--HG--
extra : amend_source : d4cb9eddf48e08446469d2e1891f0e9ed3bb85d0
The rules in the .gitignore file are duplicated by the root-level
.gitignore file, and the .hgignore file does not take effect because
hg does not subdirectory ignore files.
DONTBUILD
ParmVarDecl being a subclass of VarDecl, using two matchers then caused
ScopeChecker::check to be called twice for ParmVarDecl nodes, once for
each match. But the code in ScopeCheck::check is written with the
assumption that it's called only once for such nodes.
Somehow, this didn't cause problems with clang up to version 6, but
makes the plugin spuriously warn about already_AddRefed not being used
as temporaries when used as argument in function declarations, with
clang 7.
Differential Revision: https://phabricator.services.mozilla.com/D6360
--HG--
extra : moz-landing-system : lando
The original regex could match linux&mac outputs that look like:
`/[...]/ffmpeg/FFmpegVideoDecoder.cpp:315:6: error: expected expression`
However on Windows the same outputs have a different line&column format:
`c:/[...]/ffmpeg/FFmpegVideoDecoder.cpp(315,7): error: expected expression`
Differential Revision: https://phabricator.services.mozilla.com/D6442
--HG--
extra : moz-landing-system : lando
And remove the ADBScanner once the extension is uninstalled.
When RuntimeScanners.add is called for ADBScanner, RuntimeScanner calls
ADBScanner.enable(), thus ADB.start() is called. Meanwhile WebIDE installs the
devtools adb extension if the extension hasn't installed yet. So if the
ADB.start() is called before the installation finishes, ADB.start() fails.
Differential Revision: https://phabricator.services.mozilla.com/D6466
--HG--
extra : moz-landing-system : lando
