beanz added inline comments.
================
Comment at: clang/test/SemaHLSL/resource_binding_attr_error.hlsl:15
+// expected-error@+1 {{invalid space specifier 's2' used; expected 'space'
followed by an integer, like space1}}
+cbuffer a : register(b0, s2) {
+
----------------
aaron.ballman wrote:
> python3kgae wrote:
> > aaron.ballman wrote:
> > > Isn't this a re-definition of `a` which would cause an error?
> > The name for cbuffer is not used.
> > And no error should be reported for re-definition.
> >
> > Discussed with the team, have to keep it like this for back-compat reason.
> Wow.
>
> Please either add a comment explaining why this bizarre situation gets no
> diagnostic, or change the identifiers used so nobody else gets confused by
> this when reading the test file.
`cbuffer` is really weird (and hopefully someday will disappear entirely). From
a language perspective it behaves almost more like a named anonymous namespace
than a datatype (yea, I know that sentence makes no sense).
The functionality that it provides is the ability to group a set of global
constant variables so that the CPU-code can pack and provide those constants in
known clumps.
One might ask why have them named at all? Which is a fair question... The names
do get exposed via the CPU-side reflection API which supports querying bindings
and the like. We _probably_ shouldn't have ever allowed duplicate names, but as
long as they have unique "slot" bindings the names don't really matter.
`cbuffers` are important because we try to strip unused resources from shaders
(because resource binding costs time). A `cbuffer` can either be striped
entirely or not at all, which prevents individual binding elements from being
stripped and simplifies shader calling code so the caller doesn't need to
condition binding every individual resource element.
We have newer structures in the language which can handle all of the use cases
for `cbuffer`, however there are still some cases (particularly targeting older
versions of windows), where `cbuffer` is still the dominant technique.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D130033/new/
https://reviews.llvm.org/D130033
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
