| Age | Commit message (Collapse) | Author |
|---|
|
By default, function parameters in HLSL are mutable, but any changes to a parameter do not affect the values of the arguments after a call:
void f(int a)
{
a++; // allowed, but kind of useless
}
...
int b = 0;
f(b);
// b is still zero
Because the above behavior is a part of HLSL, we cannot easily diagnose such cases as errors without breaking backward compatibility with existing code.
This change makes it an error to invoke a `[mutating]` method on a function parameter, which cannot affect backward compatibility since the notion of `[mutating]` methods is not present in existing HLSL code:
struct Counter
{
int _state;
[mutating] void increment() { _state++; }
}
void f(Counter a)
{
a.increment(); // ERROR
}
...
Counter b = { 0 };
f(b);
// b is still zero
The compiler will also diagnose calls to `[mutating]` methods on a field or array element extracted out of a function parameter.
This change does not affect code that directly mutates a function parameter via assignment, or via passing the parameter onward as an argument to an `out` or `inout` call (or, equivalently, as the left-hand operand to a compound assignment operator).
This is a breaking change to existing Slang code, since it could diagnose an error on code that used to be allowed.
Indeed, two tests in the Slang test suite had to be updated to avoid such errors.
It would be possible to turn this diagnostic into a warning, and simply encourage users to enable it as an error.
On balance, though, it seems best to not allow this idiom since it has such a high probability to be an error.
Note: the specific case that motivated this change is use of `RayQuery` values as function parameters.
The root of the problem there is that dxc treats `RayQuery` values as copyable handles to mutable state, while Slang prefers to capture the mutation that occurs through marking the appropriate methods as `[mutating]`.
The Slang approach makes portable codegen for D3D/Vulkan simpler, but requires that we *also* treat a type like `RayQuery` as non-copyable.
This change does not address the problem that the Slang compiler does not enforce the requirement that values of non-copyable types do not get copied.
Instead, the diagnostic here just happens to issue a diagnostic in one important case where a copy would typically occur.
Co-authored-by: Yong He <yonghe@outlook.com>
|
|
* Preserve type cast during AST constant folding.
Fixes #2891.
* Fix.
* Fix truncating.
* fix test.
---------
Co-authored-by: Yong He <yhe@nvidia.com>
|
|
|
|
The problem would manifest for any code that declared a DXR 1.1 `RayQuery` value, but then only used it as one location in their code.
The most common way for this to arise in user code was declaring a `RayQuery` and then handing it off to a helper/worker subroutine.
RayQuery<0> myRayQuery;
helperRoutine(myRayQuery, ...);
The root cause was in the emit logic, where the initialization of `myRayQuery` above (a `defaultConstruct` operation in our IR) was getting folded into its (only) use site.
This folding makes some sense, because the initialization of a ray query is not an operation with side effects, but doesn't work in practice because our way of handling default construction in HLSL output is by using a variable declaration.
The simple fix here is to ensure that `defaultConstruct` instructions never get folded into use sites.
If we decide to revisit the logic here, it might be possible to separate out the case where a `defaultConstruct` is being used as a stand-alone instruction, where we can emit it as:
RayQuery<0> myRayQuery;
versus cases where the `defaultConstruct` is being used as a sub-expression, such as:
helperRoutine(RayQuery<0>(), ...);
Whether or not we can emit the latter form (or if it would be equivalent) depends on details of how constructors like this are being implemented in dxc.
For now it seems safest to emit things in a form that is obviously expected to work.
Aside: Historically, the HLSL language has had no notion of "constructors" as being a thing.
A variable that is declared but not initialized in HLSL has always been left uninitialized, since the first version of the language.
The `RayQuery` type in DXR 1.1 is the first example of a type that appears to have a C++-style "default constructor," although HLSL as implemented by dxc still does not expose constructors as a user-visible or documented feature.
(There is the small detail that the DXR 1.0 `HitGroup` type also relied on C++ constructor syntax, but I'm not aware of anybody using that feature right now, so it is mostly a curiosity.)
|
