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
Without this, OutOfLineTemplateShouldntHaveContextSym had two
definition target records that disagreed on the contextsym:
1. The first one was generated when traversing the declaration, because
it forwards to the definition if out-of-line (see comment in
TraverseFunctionDecl).
We didn't reset CurDeclContext, so it looked as-if the definition
appeared inside the declaration, leading to a bogus contextsym
(pointing to the function itself).
2. The second one was generated later on when traversing the definition
itself. This one had a correct contextsym (ie. none).
This introduces a ValueRollback helper to make sure we don't forget to
rollback CurDeclContext afterwards. (inspired by QScopedValueRollback)
See https://github.com/mozsearch/mozsearch/pull/820
Differential Revision: https://phabricator.services.mozilla.com/D224609
This disables reformating macros that are longer than a given threshold
as they take too long to reformat (and too much memory when
ColumnLimit != 0).
The threshold is lower when the macro expansion in located in a file
that is likely to be included from multiple TUs.
See https://github.com/mozsearch/mozsearch/pull/815
Differential Revision: https://phabricator.services.mozilla.com/D224608
This is quite an improvement on the quirks of the previous GDI scaling.
It also mostly supports the windows 10+ "Make text bigger" setting: it
reads the value from the registry (albeit at an unofficial location),
but doesn't register a key change listener to update the value if it
changes while the application is open. I think this is very, very likely
to be good enough; I will be surprised if someone notices this
deficiency! The official API is part of UWP and is accessible through
C++ libraries, but not conveniently through win32 APIs, which is why I
use the registry.
Differential Revision: https://phabricator.services.mozilla.com/D221544
This patch adds a new macOS sdk (15.0) toolchain.
Additionally, the SDK is updated for custom-car builds as those tasks
were previously failing on an outdated SDK.
Differential Revision: https://phabricator.services.mozilla.com/D223250
There's no point to activate -fstrict-flex-arrays=3 as there's a lot of
situation where the char [0] syntax is used, including in generated
code.
There's no point to activate -fstrict-flex-arrays=2 as at least sqlite
and icu use the char [1] syntax.
Differential Revision: https://phabricator.services.mozilla.com/D219851
As per mozglue/static/README:
> mozglue/static contains parts of the mozglue library that can/should be
> statically linked to e.g. js/Gecko.
The compression part of MFBT is a good candidate for this.
Differential Revision: https://phabricator.services.mozilla.com/D221565
There's no point to activate -fstrict-flex-arrays=3 as there's a lot of
situation where the char [0] syntax is used, including in generated
code.
Differential Revision: https://phabricator.services.mozilla.com/D219851
