mirror of
https://github.com/Gericom/teak-llvm.git
synced 2025-06-19 11:35:51 -04:00
5030928d60
initializers.
This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension in C++. Those are
resolved as follows:
* We continue to permit the full breadth of C99 designated initializers
in C++, with the exception that we disallow a partial overwrite of an
initializer with a non-trivially-destructible type. (Full overwrite
is OK, because we won't run the first initializer at all.)
* The C99 extensions are disallowed in SFINAE contexts and during
overload resolution, where they could change the meaning of valid
programs.
* C++20 disallows reordering of initializers. We only check for that for
the simple cases that the C++20 rules permit (designators of the form
'.field_name =' and continue to allow reordering in other cases).
It would be nice to improve this behavior in future.
* All C99 designated initializer extensions produce a warning by
default in C++20 mode. People are going to learn the C++ rules based
on what Clang diagnoses, so it's important we diagnose these properly
by default.
* In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
so still diagnose C99 extensions as described above. We continue to
accept designated C++20-compatible initializers in C++ <= 17 silently
by default (but naturally still reject under -pedantic-errors).
This is not a complete implementation of P0329R4. In particular, that
paper introduces new non-C99-compatible syntax { .field { init } }, and
we do not support that yet.
This is based on a previous patch by Don Hinton, though I've made
substantial changes when addressing the above interactions.
Differential Revision: https://reviews.llvm.org/D59754
llvm-svn: 370544
45 lines
1.6 KiB
Plaintext
45 lines
1.6 KiB
Plaintext
// RUN: %clang_cc1 -triple arm64 %s -verify -emit-llvm -o - -Wno-c99-designator | FileCheck %s
|
|
// expected-no-diagnostics
|
|
|
|
// Make sure we don't enter an infinite loop (rdar://21942503)
|
|
|
|
int vals1[] = {
|
|
[__objc_yes] = 1,
|
|
[__objc_no] = 2
|
|
};
|
|
// CHECK: @vals1 = global [2 x i32] [i32 2, i32 1]
|
|
|
|
int vals2[] = {
|
|
[true] = 3,
|
|
[false] = 4
|
|
};
|
|
// CHECK: @vals2 = global [2 x i32] [i32 4, i32 3]
|
|
|
|
int vals3[] = {
|
|
[false] = 1,
|
|
[true] = 2,
|
|
5
|
|
};
|
|
// CHECK: @vals3 = global [3 x i32] [i32 1, i32 2, i32 5]
|
|
|
|
int vals4[2] = {
|
|
[true] = 5,
|
|
[false] = 6
|
|
};
|
|
// CHECK: @vals4 = global [2 x i32] [i32 6, i32 5]
|
|
|
|
int vals5[3] = {
|
|
[false] = 1,
|
|
[true] = 2,
|
|
6
|
|
};
|
|
// CHECK: @vals5 = global [3 x i32] [i32 1, i32 2, i32 6]
|
|
|
|
enum SomeEnum : unsigned char {
|
|
blah = 255
|
|
};
|
|
char vals6[] = {
|
|
[blah] = 'a'
|
|
};
|
|
// CHECK: @vals6 = global [256 x i8] c"\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00a"
|