1881f648e2
OpenCL has a reserved operator (^^), the use of which was diagnosed as
an error (735c6cdebdcd4292928079cb18a90f0dd5cd65fb). However, OpenCL
also encourages working with the blocks language extension. This token
has a parsing ambiguity as a result. Consider:
unsigned x=0;
unsigned y=x^^{return 0;}();
This should result in y holding the value zero (0^0) through an
immediately invoked block call as the right-hand side of the xor
operator. However, it causes errors instead because of this reserved
token: https://godbolt.org/z/navf7jTv1
This token is still reserved in OpenCL 3.0, so we still wish to issue a
diagnostic for its use. However, we do not need to create a token for an
extension point that's been unused for about a decade. So this patch
moves the diagnostic from a parsing diagnostic to a lexing diagnostic
and no longer forms a single token. The diagnostic behavior is slightly
worse as a result, but still seems acceptable.
Part of the reason this is coming up is because WG21 is considering
using ^^ as a token for reflection, so this token may come back in the
future.
24 lines
672 B
Common Lisp
24 lines
672 B
Common Lisp
// RUN: %clang_cc1 -verify %s
|
|
// RUN: %clang_cc1 -verify %s -DBITFIELDS_EXT -triple spir
|
|
|
|
#ifdef BITFIELDS_EXT
|
|
#pragma OPENCL EXTENSION __cl_clang_bitfields : enable
|
|
#endif
|
|
|
|
struct test {
|
|
int a : 1;
|
|
#ifndef BITFIELDS_EXT
|
|
// expected-error@-2 {{bit-fields are not supported in OpenCL}}
|
|
#endif
|
|
};
|
|
|
|
void no_vla(int n) {
|
|
int a[n]; // expected-error {{variable length arrays are not supported in OpenCL}}
|
|
}
|
|
|
|
void no_logxor(int n) {
|
|
int logxor = n ^^ n; // expected-error {{^^ is a reserved operator in OpenCL}} \
|
|
expected-error {{type name requires a specifier or qualifier}} \
|
|
expected-error {{expected expression}}
|
|
}
|