Diagnose use of an implicit cast as an argument for an `out` parameter (#516)

Work on #499

Two big fixes here:

* The logic for checking constraints on `out` arguments wasn't actually triggering because it relied on function parameters being given an `OutType` if they are marked `out`, but the code wasn't actually doing that. Fixing the computation of types for functions resolved that issue.

* Next, I added a specific diagnostic to follow up the "expected an l-value" error to let the user know that their argument was implicitly converted, and that is why it doesn't count as an l-value in Slang's rules.

I've added a test case to ensure that we retain this diagnostic until we can do a true fix for the issue.

The right long-term fix is to have an AST representation of all the implicit casts involved (e.g., in both directions for an `inout` parameter), and then have the IR generate explicit code for the conversions in each direction (the `LoweredVal` representation can handle this sort of thing).

1 files changed, 7 insertions, 0 deletions

diff --git a/tests/diagnostics/implicit-cast-lvalue.slang.expected b/tests/diagnostics/implicit-cast-lvalue.slang.expected
new file mode 100644
index 000000000..e5685fc51
--- /dev/null
+++ b/tests/diagnostics/implicit-cast-lvalue.slang.expected
@@ -0,0 +1,7 @@
+result code = -1
+standard error = {
+tests/diagnostics/implicit-cast-lvalue.slang(14): error 30047: argument passed to parameter '0' must be l-value.
+tests/diagnostics/implicit-cast-lvalue.slang(14): note 30048: argument was implicitly cast from 'int' to 'uint', and Slang does not support using an implicit cast as an l-value
+}
+standard output = {
+}