In at least some libstdc++ versions, std::pair (which we want to be
memmovable) inherits from __pair_base. We have a similar setup
already for __atomic_base.
Differential Revision: https://phabricator.services.mozilla.com/D23698
--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
Clang 8 seems to generate destructor decls from different source
locations which breaks an assertion in the code. This patch updates the
code to remove the assertion and more robustly handle the new
declarations.
Differential Revision: https://phabricator.services.mozilla.com/D17902
--HG--
extra : moz-landing-system : lando
In the first part of bug 1501903, paths were canonicalized in
inThirdPartyPath. For some reason, this seems to add a non-negligible
overhead on Windows. OTOH, most include paths handed by the build system
are absolute, and most paths that contains .. are for system headers,
which don't matter for the inThirdPartyPath test.
Considering the inThirdPartyPath has been using non-canonicalized paths
for the longest, we'll assume it's fine to come back to that mode.
Differential Revision: https://phabricator.services.mozilla.com/D11725
--HG--
extra : moz-landing-system : lando
While looking at this code I found a couple of places where errors could
get ignored or silently discarded and result in corrupt data. This
checks for the errors and fails harder.
Depends on D10353
Differential Revision: https://phabricator.services.mozilla.com/D10354
--HG--
extra : moz-landing-system : lando
This is necessary because:
(a) the JSONFormatter emits a \n newline for each analysis line
(b) we truncate the file to the expected length after writing it
(c) on Windows writing the file in text mode replaces \n with \r\n
and invalidates our computed "expected length"
Differential Revision: https://phabricator.services.mozilla.com/D10353
--HG--
extra : moz-landing-system : lando
The function is called a lot for the same paths and is rather costly, so
cache the results for each path.
Depends on D9758
Differential Revision: https://phabricator.services.mozilla.com/D9759
--HG--
extra : moz-landing-system : lando
SourceLocation that are passed to inThirdPartyPath might be macro
expansion locations, for which SourceManager.getFilename returns the
path of the directory containing the source, rather than of the
expansion location.
Furthermore, the paths getFileName returns are not canonical, and can
contain e.g. `..`.
Differential Revision: https://phabricator.services.mozilla.com/D9758
--HG--
extra : moz-landing-system : lando
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
- We forcefully remove annotations from the AST so that they don't end
up impacting codegen.
- We change the API such that we use identifiers instead of strings,
reducing the chances of typo errors.
Differential Revision: https://phabricator.services.mozilla.com/D5493
--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 just enough host shared library support for this one use case,
but also takes shortcuts, because fully supporting host shared library
is a deep rabbit hole I'm not ready to take just to fix --enable-lto
--enable-clang-plugin on mac builds.
One downside is that one my machine the plugin now takes > 80s to build,
instead of 15s before, thanks to the lack of unified sources.
--HG--
extra : rebase_source : bf52a72a01d4e3eb77cf52b646b19734b9273075
The linux64-clang toolchain alias is currently clang 5. Switch it to
clang 6, but keep the spidermonkey tsan builds on clang 5 because of
bug 1467673.
The LLVM headers that come with clang 6 contain a DEBUG define that
conflicts with our DEBUG define and breaks the clang-plugin build,
so force unset ours.
--HG--
extra : rebase_source : aae88f1166108f003b06c022f14d5f4c61fc1ed9
Also work around https://bugs.llvm.org/show_bug.cgi?id=37746 by
explicitly handling ObjC interface variables separately. This actually
allows the searchfox macosx build to go much further than it used to (it
now fails during make package with apparently no output for rust code)
--HG--
extra : rebase_source : 354981ca9deebed5c60d3684f5c3abc554422393
The check for whether an implicit constructor is in a third-party
directory currently has a homegrown list of directories to ignore.
Let's move this over to the (more complete!) list of third-party
directories maintained elsewhere.
It's much easier to find that way, specially for functions with tons of
argument.
MozReview-Commit-ID: i3PMjDOcH7
--HG--
extra : rebase_source : 2c79f0b4eb5c6022c3896ded3bd26ceda524ce5a
In some cases we have SourceLocation objections that are isMacroId()
rather than isFileId() and so don't have a filename at all. In other
cases the filename is something clang-internal like "<scratch>". In
both of these situations we don't want to output any analysis data.
However, the code previously was taking the empty filename and resolving
it relative to the source folder, and then tried to write to the
source folder or create a file corresponding to a subfolder. This
resulted in general badness. This patch makes sure we ignore analysis
from places that don't have a corresponding file so that we don't
have this problem.
MozReview-Commit-ID: 7WluygY9Uy8
--HG--
extra : rebase_source : 35d7e71fc05bbd5a3357a57db9de25782178622a
This adds an RAII class and macro that can be quickly added in functions
to log entry/exit from the function. This is useful to debugging.
MozReview-Commit-ID: 4Ud8jLOxI0R
--HG--
extra : rebase_source : 518d30fe44dff67bffb186e23c1eb858c02280af
