Details

This patch adds the concept of "sizeless" types to C and C++.
The documentation part of the patch describes the extension in
detail and explains the rationale. The patch is a prerequisite
for adding AArch64 SVE intrinsic functions.

The main change is to make several checks use the new distinction
between "definite" and "indefinite" types instead of the usual
distinction between "complete" and "incomplete" types. There are
also a couple of places that check specifically for sizeless types.

The patch doesn't reword the diagnostics to talk about indefinite
types rather than incomplete types since (a) "indefinite" won't
mean much to most users and (b) the patch shouldn't affect the user
experience for non-AArch64 targets.

The FIXMEs about inline asms are resolved by later SVE patches.

The change to DiagnoseForRangeVariableCopies is for consistency.
As the tests show, DiagnoseForRangeReferenceVariableCopies can apply
to sizeless types, but at the moment DiagnoseForRangeConstVariableCopies
(which is the only part affected by the completeness check) doesn't
warn for PODs, and so doesn't warn for sizeless types either.

Yeah, that's right. But AIUI __atomic_always_lock_free(N, P) asks whether an N-byte access at P is lock-free (where P can be null to query standard alignment). So the question isn't whether sizeless types are lock-free, but whether an N-byte access is lock-free given the alignment guarantees of P. For this line the answer would be yes if &local_int8 was aligned to a 2-byte boundary.

The query isn't really that interesting for sizeless types. The reason for having it is that IntExprEvaluator::VisitBuiltinCallExpr says that 1-byte accesses are lock-free if the target has lock-free accesses, whatever P happens to be. But for larger N it punts when P is a pointer to incomplete type, because in that case it knows nothing about the alignment of P. The test is enforcing this behaviour for sizeless types too.

Since this is an extension, it wouldb be great to have a (on-by-default? at least in -Wall) diagnostic for every instance of usage of this extension.
(I guess this is actually true for clang vector extension, too..)

Since this is an extension, it wouldb be great to have a (on-by-default? at least in -Wall) diagnostic for every instance of usage of this extension.

We generally only add warnings for extensions which are not allowed by the standard. It's impossible to define a sizeless type without using a reserved keyword, like __SVInt8_t, so we don't need a warning.