Justin Bogner d35bf17e8a
[HLSL] Add a warning for implicit bindings (#135909)
Implicit bindings will cause very confusing crashes in the backend at
present, so this is intended at least partially as a stop gap until we
get them implemented (see #110722).

However, I do think that this is useful in the longer term as well as an
off-by-default warning, as it is quite easy to miss a binding or two
when using explicit bindings and the results of that can be surprisingly
hard to debug. I've filed #135907 to track turning this into an
off-by-default warning or removing it eventually as we see fit.
2025-04-16 15:45:18 -07:00

62 lines
1.2 KiB
HLSL

// RUN: %clang_cc1 -Wno-hlsl-implicit-binding -triple dxil-pc-shadermodel6.3-library -x hlsl -o - -fsyntax-only %s -verify
// expected-note@+1 {{declared here}}
cbuffer a {
int x;
};
int foo() {
// expected-error@+1 {{'a' does not refer to a value}}
return sizeof(a);
}
// expected-error@+1 {{expected unqualified-id}}
template <typename Ty> cbuffer a { Ty f; };
// For back-compat reason, it is OK for multiple cbuffer/tbuffer use same name in hlsl.
// And these cbuffer name only used for reflection, cannot be removed.
cbuffer A {
float A;
}
cbuffer A {
float b;
}
tbuffer A {
float a;
}
float bar() {
// cbuffer/tbuffer name will not conflict with other variables.
return A;
}
cbuffer a {
// expected-error@+2 {{unknown type name 'oh'}}
// expected-error@+1 {{expected ';' after top level declarator}}
oh no!
// expected-warning@+1 {{missing terminating ' character}}
this isn't even valid HLSL code
despite seeming totally reasonable
once you understand that HLSL
is so flaming weird.
}
tbuffer B {
// expected-error@+1 {{unknown type name 'flaot'}}
flaot f;
}
// None of these should produce an error!
cbuffer EmptyCBuffer {}
cbuffer EmptyDeclCBuffer {
;
}
cbuffer EmptyDecl2CBuffer {
;
int X;
}