The patch was added back in bug 1661129 to work around
https://bugs.llvm.org/show_bug.cgi?id=47258 and the patch now doesn't
apply anymore after changes on clang trunk. OTOH, it also seems that the
problem described in the llvm bug report doesn't happen anymore, so just
get rid of the patch.
Differential Revision: https://phabricator.services.mozilla.com/D169292
These flags used to be necessary when we first were cross-compiling
clang, but more recent (although now old) changes have made them
actually unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D168033
These flags used to be necessary when we first were cross-compiling
clang, but more recent (although now old) changes have made them
actually unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D168033
In bug 1811960, the change was fully reverted, but that now conflicts with
more recent changes to clang trunk. So instead, we only revert the part that
affects the writing of the profile data files.
Differential Revision: https://phabricator.services.mozilla.com/D168404
Using ThinLTO because it's a good compromise between performance and
compilation speed.
Activating it for both profile generation and profile usage, doing it
only for profile usage leads to a lot of mismatch, aka
function control flow change detected (hash mismatch)
which leads to profile information not beoing used.
This requires using the whole llvm toolchain (lld, llvm-ar, llvm-ranlib)
from the same revision.
This is disabled on Windows where it causes link error on the LLVM
Plugin system.
Differential Revision: https://phabricator.services.mozilla.com/D162371
It was only really needed when we were still using rustc 1.64 (llvm 14),
but now that we have a rustc based on the same llvm version as clang, we
don't need it anymore (and it doesn't apply cleanly on trunk anymore).
Differential Revision: https://phabricator.services.mozilla.com/D163267
Ported from clangd, this still can be improved over time, but it can be landed.
This was based on the work from https://bit.ly/3TkV2N1
* The utility makes the assumption that all header are self contained!
* It only checkes `Decls` from the main translation file, where SourceLocarion is the
passed `cpp` file.
* It builds a list with all of the includes from the translation unit.
* It matches all of the `Decls` from the main translation units with definitions from the
included header files and builds a list with used header files.
* All of the includes that are not part of the matched used header files are considered
to be unused. Of course this is correct if the first assumption if followed by the coding guide,
where all of the header are self contained. Since the mozilla code base doesn't follow this approach
false positives might appear where the is the following situation:
FOO.cpp
#include <A>
#Include <B>
If header `A` defines a symbol that is used by header `B` and `B` doesn't include `A` nor
it has symbols defined that are used by `FOO.cpp` then `B` it will be marked as potentially to be removed
by the tool.
This is the limitation determined by header that are not self contained.
The limitation presented above can be fixed in the future with extra work, but it's very time expensive
during the runtime of the checker.
Differential Revision: https://phabricator.services.mozilla.com/D161583
Ported from clangd, this still can be improved over time, but it can be landed.
This was based on the work from https://bit.ly/3TkV2N1
* The utility makes the assumption that all header are self contained!
* It only checkes `Decls` from the main translation file, where SourceLocarion is the
passed `cpp` file.
* It builds a list with all of the includes from the translation unit.
* It matches all of the `Decls` from the main translation units with definitions from the
included header files and builds a list with used header files.
* All of the includes that are not part of the matched used header files are considered
to be unused. Of course this is correct if the first assumption if followed by the coding guide,
where all of the header are self contained. Since the mozilla code base doesn't follow this approach
false positives might appear where the is the following situation:
FOO.cpp
#include <A>
#Include <B>
If header `A` defines a symbol that is used by header `B` and `B` doesn't include `A` nor
it has symbols defined that are used by `FOO.cpp` then `B` it will be marked as potentially to be removed
by the tool.
This is the limitation determined by header that are not self contained.
The limitation presented above can be fixed in the future with extra work, but it's very time expensive
during the runtime of the checker.
Differential Revision: https://phabricator.services.mozilla.com/D161583
