LLVM r356397 added some new warnings to the compiler that in this file complain about `size argument is too large; destination buffer has size 100, but size argument is 101`.
The easiest path is to just remove those lines; doing so doesn't really weaken the test coverage of the SprintfLiteral checker.
Differential Revision: https://phabricator.services.mozilla.com/D36515
--HG--
extra : moz-landing-system : lando
LLVM r356397 added some new warnings to the compiler that in this file complain about `size argument is too large; destination buffer has size 100, but size argument is 101`.
The easiest path is to just remove those lines; doing so doesn't really weaken the test coverage of the SprintfLiteral checker.
Differential Revision: https://phabricator.services.mozilla.com/D36515
--HG--
extra : moz-landing-system : lando
Some of our builds use --enable-warnings-as-errors and some don't, and I can't
figure out a way to write an expectation comment for that.
Differential Revision: https://phabricator.services.mozilla.com/D24469
--HG--
extra : moz-landing-system : lando
Since these are compile-time constants, they can't exactly go away on us due to
running script, right?
Differential Revision: https://phabricator.services.mozilla.com/D24195
--HG--
extra : moz-landing-system : lando
We need to typecheck the trivials too, not just the final thing after trivials
are stripped, because casts are trivials.
Differential Revision: https://phabricator.services.mozilla.com/D24186
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
"this" is guaranteed to stay alive as long as other MOZ_CAN_RUN_SCRIPT
conditions hold, and its const members can't change value and drop
their refs.
Differential Revision: https://phabricator.services.mozilla.com/D23997
--HG--
extra : moz-landing-system : lando
Since these are compile-time constants, they can't exactly go away on us due to
running script, right?
Differential Revision: https://phabricator.services.mozilla.com/D24195
--HG--
extra : moz-landing-system : lando
We need to typecheck the trivials too, not just the final thing after trivials
are stripped, because casts are trivials.
Differential Revision: https://phabricator.services.mozilla.com/D24186
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
"this" is guaranteed to stay alive as long as other MOZ_CAN_RUN_SCRIPT
conditions hold, and its const members can't change value and drop
their refs.
Differential Revision: https://phabricator.services.mozilla.com/D23997
--HG--
extra : moz-landing-system : lando
This allows calling a C++ MOZ_CAN_RUN_SCRIPT method that takes a callback argument.
The changes to TestCanRunScript.cpp are there to catch an incorrect change I was
going to make to the analysis to make this work, until I figured out that
RootedCallback should be MOZ_IS_SMARTPTR_TO_REFCOUNTED.
Differential Revision: https://phabricator.services.mozilla.com/D23519
--HG--
extra : moz-landing-system : lando
This way if a caller calls a method that has a MOZ_CAN_RUN_SCRIPT override, it
can detect that it's possibly calling a MOZ_CAN_RUN_SCRIPT thing without having
to know about the override.
Differential Revision: https://phabricator.services.mozilla.com/D22839
--HG--
extra : moz-landing-system : lando
As per bug 1487622, annotations have side effects on codegen, one of
which changes a leak signature that the wpt harness doesn't match
against its whitelist anymore.
Interestingly, while looking at the issue, I found multiple moz_*
annotations that weren't actually looked for by the clang plugin,
making them useless. Even more interestingly, removing them changes
codegen in such a way that the leak signature mentioned above is not
altered anymore.
Differential Revision: https://phabricator.services.mozilla.com/D5000
This adds a `moz_temporary_class` annotation that can be used to indicate
a class is intended to only be used as a temporary.
--HG--
extra : rebase_source : 2c4d5f0946739eafba485053624199bd4a05107a
Such a shame that the functionDecl() matcher doesn't handle them. I didn't find
a cleaner way to handle them, but I'm a 100% noob with AST matchers, so there
may be a more elegant way to do this.
MozReview-Commit-ID: 3HJQdFpN4hy
--HG--
extra : rebase_source : 27e48e6fb264499fd99e75eb54a22276758ab3e4
David Major
Mihai Alexandru Michis
Boris Zbarsky
Brindusan Cristian
Masatoshi Kimura
Mike Hommey
Myk Melez
Andi-Bogdan Postelnicu
Jeff Walden
Emilio Cobos Álvarez
Chris Peterson
Eric Rahm
Julian Hector
Nika Layzell
Chris Manchester
Tristan Bourvon
Carsten "Tomcat" Book
Michael Layzell