Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.
Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
support::endianness with llvm::endianness.
An .ARM.attributes section is divided into subsections, each labelled
with a vendor name. There is one standardised vendor name, which must
be used for all attributes that affect compatibility. Subsections
labelled with other vendor names can be used for optimisation
purposes, but it has to be safe for an object file consumer to ignore
them if it doesn't recognise the vendor name.
LLD currently terminates parsing of the whole attributes section as
soon as it encounters a subsection with a vendor name it doesn't
recognise (which is anything other than the standard one). This can
prevent it from detecting compatibility issues, if a standard
subsection followed the vendor-specific one.
This patch modifies the attribute parser so that unrecognised vendor
subsections are silently skipped, and the subsections beyond them are
still processed.
(Relanded with no change from the original commit 8f208edd44d0832. I
reverted it in 949bb7e4de62cd0 due to widespread buildbot breakage,
failing to notice that 975f71faa72aaaa had already fixed the failing
unit test. Also, the *revert* caused at least one buildbot to fail,
because I switched the affected lld test to making %t a directory, and
then the reverted version tried to treat it as a file without cleaning
the output directory first.)
Differential Revision: https://reviews.llvm.org/D153335
This reverts commit 8f208edd44d0832ac2580e0ec4238be4ecfd5737.
I completely missed the compiled unit test for ELFAttributeParser,
which also needs updating. I'll reland this change once I make further
fixes.
An .ARM.attributes section is divided into subsections, each labelled
with a vendor name. There is one standardised vendor name, which must
be used for all attributes that affect compatibility. Subsections
labelled with other vendor names can be used for optimisation
purposes, but it has to be safe for an object file consumer to ignore
them if it doesn't recognise the vendor name.
LLD currently terminates parsing of the whole attributes section as
soon as it encounters a subsection with a vendor name it doesn't
recognise (which is anything other than the standard one). This can
prevent it from detecting compatibility issues, if a standard
subsection followed the vendor-specific one.
This patch modifies the attribute parser so that unrecognised vendor
subsections are silently skipped, and the subsections beyond them are
still processed.
Differential Revision: https://reviews.llvm.org/D153335
Use deduction guides instead of helper functions.
The only non-automatic changes have been:
1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).
Per reviewers' comment, some useless makeArrayRef have been removed in the process.
This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.
Differential Revision: https://reviews.llvm.org/D140955
Check ScopedPrinter pointer before attempting to print the attribute's
parsed information.
Patch by Michael Platings and Victor Campos
Reviewed By: pratlucas
Differential Revision: https://reviews.llvm.org/D132214
The cleanup was manual, but assisted by "include-what-you-use". It consists in
1. Removing unused forward declaration. No impact expected.
2. Removing unused headers in .cpp files. No impact expected.
3. Removing unused headers in .h files. This removes implicit dependencies and
is generally considered a good thing, but this may break downstream builds.
I've updated llvm, clang, lld, lldb and mlir deps, and included a list of the
modification in the second part of the commit.
4. Replacing header inclusion by forward declaration. This has the same impact
as 3.
Notable changes:
- llvm/Support/TargetParser.h no longer includes llvm/Support/AArch64TargetParser.h nor llvm/Support/ARMTargetParser.h
- llvm/Support/TypeSize.h no longer includes llvm/Support/WithColor.h
- llvm/Support/YAMLTraits.h no longer includes llvm/Support/Regex.h
- llvm/ADT/SmallVector.h no longer includes llvm/Support/MemAlloc.h nor llvm/Support/ErrorHandling.h
You may need to add some of these headers in your compilation units, if needs be.
As an hint to the impact of the cleanup, running
clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 8000919 lines
after: 7917500 lines
Reduced dependencies also helps incremental rebuilds and is more ccache
friendly, something not shown by the above metric :-)
Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
We can build it with -Werror=global-constructors now. This helps
in situation where libSupport is embedded as a shared library,
potential with dlopen/dlclose scenario, and when command-line
parsing or other facilities may not be involved. Avoiding the
implicit construction of these cl::opt can avoid double-registration
issues and other kind of behavior.
Reviewed By: lattner, jpienaar
Differential Revision: https://reviews.llvm.org/D105959
We can build it with -Werror=global-constructors now. This helps
in situation where libSupport is embedded as a shared library,
potential with dlopen/dlclose scenario, and when command-line
parsing or other facilities may not be involved. Avoiding the
implicit construction of these cl::opt can avoid double-registration
issues and other kind of behavior.
Reviewed By: lattner, jpienaar
Differential Revision: https://reviews.llvm.org/D105959
We can build it with -Werror=global-constructors now. This helps
in situation where libSupport is embedded as a shared library,
potential with dlopen/dlclose scenario, and when command-line
parsing or other facilities may not be involved. Avoiding the
implicit construction of these cl::opt can avoid double-registration
issues and other kind of behavior.
Reviewed By: lattner, jpienaar
Differential Revision: https://reviews.llvm.org/D105959
This implementation of `ELFDumper<ELFT>::printAttributes()` in llvm-readobj has issues:
1) It crashes when the content of the attribute section is empty.
2) It uses `unwrapOrError` and `reportWarning` calls, though
ideally we want to use `reportUniqueWarning`.
3) It contains a TODO about redundant format version check.
`lib/Support/ELFAttributeParser.cpp` uses a hardcoded constant instead of the named constant.
This patch fixes all these issues.
Differential revision: https://reviews.llvm.org/D92318
Leverage ARM ELF build attribute section to create ELF attribute section
for RISC-V. Extract the common part of parsing logic for this section
into ELFAttributeParser.[cpp|h] and ELFAttributes.[cpp|h].
Differential Revision: https://reviews.llvm.org/D74023
