Add warning on mutation of function parameter (#3067)

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>

0 files changed, 0 insertions, 0 deletions