From 256d7621671544578a2b92777d525a8805df39d1 Mon Sep 17 00:00:00 2001 From: Chris Bieneman Date: Tue, 15 Apr 2025 08:31:08 -0500 Subject: [PATCH 1/3] Add an initial proposal for HLSL 202x deprecations This proposal seeks to enumerate the smaller features that should be deprecated or significantly tightened in HLSL 202x, which are not large enough to indipendently warrant their own proposal documents. These features represent technical debt in DXC's implementation of HLSL which should be removed in future language versions to avoid carrying it forward indefinitely. --- proposals/NNNN-202x-deprecations.md | 64 +++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 proposals/NNNN-202x-deprecations.md diff --git a/proposals/NNNN-202x-deprecations.md b/proposals/NNNN-202x-deprecations.md new file mode 100644 index 00000000..73d6068e --- /dev/null +++ b/proposals/NNNN-202x-deprecations.md @@ -0,0 +1,64 @@ + + +# 202x Feature Deprecations + +* Proposal: [NNNN](NNNN-202x-deprecations.md) +* Author(s): [Chris Bieneman](https://github.com/llvm-beanz) +* Sponsor: TBD +* Status: **Under Consideration** +* Planned Version: 202x +* Issues: [#300](https://github.com/microsoft/hlsl-specs/issues/380), + [#291](https://github.com/microsoft/hlsl-specs/issues/291), + [#259](https://github.com/microsoft/hlsl-specs/issues/259), + [#135](https://github.com/microsoft/hlsl-specs/issues/135), + [LLVM #117715](https://github.com/llvm/llvm-project/issues/117715) + +## Introduction + +HLSL 2021 supports syntaxes and features that either do nothing, or are +potentially confusing. This proposal tracks a set of minimal breaking changes +for HLSL to remove misleading or confusing functionality. + +## Motivation + +This proposal is part of a larger effort to reduce carried forward technical +debt in HLSL compiler implementations. + +## Proposed solution + +### Removal of Effects Syntax + +DXC supports parsing much of the legacy FXC effects syntax, however it emits +warnings and does not provide any behavior associated with the effects syntax. + +In HLSL 202x we should disable effects parsing support and allow those parsing +failures to generate errors as would otherwise occur in HLSL. + +### Removal of `interface` Keyword + +DXC supports `interface` declarations, however the semantic utility of +interfaces is limited. Instances of interfaces cannot be created or passed +around to functions. They can only be used as a static-verification that all +required methods of an object are implemented. + +Template-based polymorphic patterns available in HLSL 2021 and later enable many +of the code patterns that `interface` declarations would have previously been +used for and should be the supported path going forward. + +### Removal of `uniform` Keyword + +In DXC the `uniform` keyword is parsed and ignored. This may lead users to +believing it has some impact when it does not. We should remove it. + +## Stricter restrictions on cbuffer Members + +DXC's implementation of `cbuffer` declarations allows all sorts of declarations +inside the scope of a `cbuffer`, and does not interoperate well with C++ +namespaces. + +In HLSL 202x we should disallow any declaration that isn't a variable +declaration to be a member of a cbuffer, and we should seek to clearly define +the relationship between cbuffer declarations and their enclosing scope (i.e. +namespace). + + From a966c38189a9f16ed80e3460c1bf751d79ee55fb Mon Sep 17 00:00:00 2001 From: Chris Bieneman Date: Tue, 29 Apr 2025 08:33:47 -0500 Subject: [PATCH 2/3] Update cbuffer changes --- proposals/NNNN-202x-deprecations.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/proposals/NNNN-202x-deprecations.md b/proposals/NNNN-202x-deprecations.md index 73d6068e..15ace7bd 100644 --- a/proposals/NNNN-202x-deprecations.md +++ b/proposals/NNNN-202x-deprecations.md @@ -50,15 +50,11 @@ used for and should be the supported path going forward. In DXC the `uniform` keyword is parsed and ignored. This may lead users to believing it has some impact when it does not. We should remove it. -## Stricter restrictions on cbuffer Members +## Disallow `cbuffer` initializers -DXC's implementation of `cbuffer` declarations allows all sorts of declarations -inside the scope of a `cbuffer`, and does not interoperate well with C++ -namespaces. - -In HLSL 202x we should disallow any declaration that isn't a variable -declaration to be a member of a cbuffer, and we should seek to clearly define -the relationship between cbuffer declarations and their enclosing scope (i.e. -namespace). +DXC allows variables within a `cbuffer` to have initializer clauses. The +initializer clauses are ignored, and DXC does not issue a diagnostic. In HLSL +202x initializer clauses on declarations placed into an implicit or explicit +`cbuffer` declaration are illegal and will produce an error. From 5f136cb75626d3df153286bdf8014133533c29ab Mon Sep 17 00:00:00 2001 From: Chris Bieneman Date: Tue, 29 Apr 2025 08:53:31 -0500 Subject: [PATCH 3/3] Add effects syntax examples --- proposals/NNNN-202x-deprecations.md | 30 +++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/proposals/NNNN-202x-deprecations.md b/proposals/NNNN-202x-deprecations.md index 15ace7bd..bb2a44fc 100644 --- a/proposals/NNNN-202x-deprecations.md +++ b/proposals/NNNN-202x-deprecations.md @@ -34,6 +34,36 @@ warnings and does not provide any behavior associated with the effects syntax. In HLSL 202x we should disable effects parsing support and allow those parsing failures to generate errors as would otherwise occur in HLSL. +#### Examples of effects syntax + +```hlsl +< int foo=1; > +< + string Name = "texa"; + int ArraySize = 3; +>; + +sampler S : register(s1) = sampler_state {texture=tex;}; +Texture2D l_tex { state=foo; }; + +int foobar2 {blah=foo;} = 5; + +texture tex1 < int foo=1; > { state=foo; }; + + +technique T0 +{ + pass {} +} +Technique +{ + pass {} +} + +int foobar5[] {1, 2, 3}; +int foobar6[4] {1, 2, 3, 4}; +``` + ### Removal of `interface` Keyword DXC supports `interface` declarations, however the semantic utility of