I had big issues with this patch as it was causing random crashes
when run with MOZ_PROFILER_STARTUP=1 and breaking browser_xpcom_graph_wait.js
which does the same.
I tried to get around that by avoiding the IOInterposer registration
in CacheIOThread, but that was also problematic.
Eventually it seems there's no longer a good reason to keep calling
PR_CreateThread manually instead of NS_NewNamedThread, so I switched
to that and all of the previous issues are gone.
The stack is now twice as big, but hopefully that's not a major issue.
All other behaviour should stay the same.
Differential Revision: https://phabricator.services.mozilla.com/D132381
This provides a way to make type-dependent statements appear as-if they
were located at the template call site.
During the analysis of the template, this first registers all type-dependent
function call locations in ForwardedTemplateLocations (we don't have more
information at this point).
Then when analyzing the template instantiations, we link the actual
type-resolved statements to the template instantiation.
Then when emitting the analysis data for a template call, we also (recursively)
emit all the analysis data for the forwarded items at the call site.
Differential Revision: https://phabricator.services.mozilla.com/D228449
This is being removed because:
1. It it the last remaining cram test in-tree
2. It doesn't run in any CI tasks
3. It doesn't appear to be a particularly high value test
Once this is removed, the cramtest harness can also be removed.
Differential Revision: https://phabricator.services.mozilla.com/D227868
-gline-tables-only is better passed to --enable-debug or
--enable-debug-symbols than via abuse of --enable-optimize.
--enable-optimize was being passed -O2 because passing
-gline-tables-only would have removed optimizations. This has the side
effect of changing the optimization level on macOS, though, so there
we keep the override.
--disable-debug is the default, remove it.
--enable-project=browser is the default, remove it.
--enable-optimize is the default, remove it.
--enable-debug-symbols is the default, remove it.
--disable-sandbox is the default on tsan builds, remove it.
--enable-optimize="-O2 -g" is, essentially, the default, remove it.
--with-android-min-sdk=21 is the default, remove it.
X11 builds only have the X11 headers, so technically speaking the
cairo-gtk3 toolkit is fine because it does the right fallback, but
using cairo-gtk3-x11-only is more explicit and would avoid surprises.
MOZ_DEBUG_SYMBOLS has been a no-op for essentially forever.
Differential Revision: https://phabricator.services.mozilla.com/D227311
For both libc++ and libstdc++, they have different macro to activate
those, and different feature check.
This is a debug-only feature, given the overhead.
Differential Revision: https://phabricator.services.mozilla.com/D220934
This patch both:
1. Provides a static checker to detect global variables which may not be
initialized at compile-time
2. Verify that variables flagged as MOZ_RUNINIT are indeed
initialized at runtime
3. In case of variables whose initialisation status varies based on
macro definition or template parameters, just flag them as
MOZ_GLOBINIT.
Differential Revision: https://phabricator.services.mozilla.com/D223342
The windows chromium-as-release (CaR) builds recently updated the
minimum windows SDK version required to complete the builds. This patch
adds this new sdk toolchain and also keeps it separate for just these
builds.
Differential Revision: https://phabricator.services.mozilla.com/D226332
It looks like the excluding logic around ThirdPartyPaths.txt works on include
paths, and not on the path of files on disk, so it's necessary to explicitly
exclude files in `fmt/`. Two checks fail as things stand today:
- the one that checks that `explicit` is used for single-arg ctors, this is used
throughout `{fmt}`
- the one that checks that `val != val` isn't used to check for NaN. This is
used in `{fmt}` because `std::isnan` doesn't have an overload for `__float128`.
This check is now ignoring third-party code.
Differential Revision: https://phabricator.services.mozilla.com/D217960
It looks like the excluding logic around ThirdPartyPaths.txt works on include
paths, and not on the path of files on disk, so it's necessary to explicitly
exclude files in `fmt/`. Two checks fail as things stand today:
- the one that checks that `explicit` is used for single-arg ctors, this is used
throughout `{fmt}`
- the one that checks that `val != val` isn't used to check for NaN. This is
used in `{fmt}` because `std::isnan` doesn't have an overload for `__float128`.
This check is now ignoring third-party code.
Differential Revision: https://phabricator.services.mozilla.com/D217960
Upstream is not interested in fixing this or even providing a flag to
disable the error, so let's patch our compiler until we can upgrade to
NDK r28 (which is not released yet).
Differential Revision: https://phabricator.services.mozilla.com/D224893
Bug 1856762 added support for traversing the implicit declarations
created for lambdas. When traversing a lambda, a new context is pushed
to the AutoSetContext stack to set the VisitImplicit flag. This context
has Decl == nullptr because the lambda is not a NamedDecl.
I modified IndexConsumer::getContext(Decl *D) to support that case, but
forgot to modify getContext(SourceLocation Loc) to support it too.
Differential Revision: https://phabricator.services.mozilla.com/D224629
By doing so, we don't really need a stage 1 clang for mac and windows
(with the downside that the final PGOed clang becomes the
clang-toolchain artifact on those platforms), and cross-compiling stage
2 is much faster as a cross-compile, leaving only stage 3 to be native.
While here, for the one build type that still does stage 2 and 3 in one
task, we actually prefer taking the llvm-profdata from stage 1, as it
doesn't contain profile instrumentation (it should actually have been
this way since the beginning).
Differential Revision: https://phabricator.services.mozilla.com/D220654
This reuses the AutoSetContext machinery initially implemented for
constructors to visit the implicit code generated for lambdas too,
giving us the data required to understand the template-dependent code
in lambdas.
AutoSetContext is adapted to support AutoSetContext::Decl == nullptr
because, contrary to CXXConstructorDecl, LambdaExprs aren't NamedDecls.
See https://github.com/mozsearch/mozsearch/pull/821
Differential Revision: https://phabricator.services.mozilla.com/D224610
