You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[clang] Introduce "binary" StringLiteral for #embed data (#127629)
StringLiteral is used as internal data of EmbedExpr and we directly use
it as an initializer if a single EmbedExpr appears in the initializer
list of a char array. It is fast and convenient, but it is causing
problems when string literal character values are checked because #embed
data values are within a range [0-2^(char width)] but ordinary
StringLiteral is of maybe signed char type.
This PR introduces new kind of StringLiteral to hold binary data coming
from an embedded resource to mitigate these problems. The new kind of
StringLiteral is not assumed to have signed char type. The new kind of
StringLiteral also helps to prevent crashes when trying to find
StringLiteral token locations since these simply do not exist for binary
data.
Fixes#119256
#embed"big_char.txt"// expected-error {{constexpr initializer evaluates to 255 which is not exactly representable in type 'const char'}}
9
+
};
10
+
11
+
static constexpr intdata2[] = {
12
+
#embed"big_char.txt"
13
+
};
14
+
15
+
static constexpr unsigneddata3[] = {
16
+
#embed "big_char.txt" suffix(, -1) // expected-error {{constexpr initializer evaluates to -1 which is not exactly representable in type 'const unsigned int'}}
0 commit comments