Sometimes a collection of multilibs has a gap in it, where a set of
driver command-line options can't work with any of the available
libraries.
For example, the Arm MVE extension requires special startup code (you
need to initialize FPSCR.LTPSIZE), and also benefits greatly from
-mfloat-abi=hard. So a multilib provider might build a library for
systems without MVE, and another for MVE with -mfloat-abi=hard,
anticipating that that's what most MVE users would want. But then if a
user compiles for MVE _without_ -mfloat-abi=hard, thhey can't use either
of those libraries – one has an ABI mismatch, and the other will fail to
set up LTPSIZE.
In that situation, it's useful to include a multilib.yaml entry for the
unworkable intermediate situation, and have it map to a fatal error
message rather than a set of actual libraries. Then the user gets a
build failure with a sensible explanation, instead of selecting an
unworkable library and silently generating bad output. The new
regression test demonstrates this case.
This patch introduces extra syntax into multilib.yaml, so that a record
in the `Variants` list can omit the `Dir` key, and in its place, provide
a `FatalError` key. Then, if that variant is selected, the error message
is emitted as a clang diagnostic, and multilib selection fails.
In order to emit the error message in `MultilibSet::select`, I had to
pass a `Driver &` to that function, which involved plumbing one through
to every call site, and in the unit tests, constructing one specially.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This will enable layering multilibs on top of each other.
For example a multilib containing only a no-exceptions libc++ could be
layered on top of a multilib containing C libs. This avoids the need
to duplicate the C library for every libc++ variant.
This change doesn't expose the functionality externally, it only opens
the functionality up to be potentially used by ToolChain classes.
Differential Revision: https://reviews.llvm.org/D143059
This new representation means that a valid command line option may
potentially be used directly as a multilib flag without any translation.
To indicate that a flag is required not to be present, its first
character is replaced with '!', which is intended for consistency with
the logical not operator in many programming languages.
Reviewed By: simon_tatham
Differential Revision: https://reviews.llvm.org/D151438
Decouple the interface of the MultilibBuilder flag method from how flags
are stored internally. Likewise change the addMultilibFlag function.
Currently a multilib flag like "-fexceptions" means a multilib is
*incompatible* with the -fexceptions command line option, which is
counter-intuitive. This change is a step towards changing this scheme.
Differential Revision: https://reviews.llvm.org/D151437
The functionality in MultilibSet for creating it is tied to its current
implementation. Putting that code in a separate class is an enabler for
changing the MultilibSet implementation.
Differential Revision: https://reviews.llvm.org/D142893
