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, 15 insertions, 0 deletions

diff --git a/tests/diagnostics/implicit-cast-lvalue.slang b/tests/diagnostics/implicit-cast-lvalue.slang
new file mode 100644
index 000000000..4bf3c13b0
--- /dev/null
+++ b/tests/diagnostics/implicit-cast-lvalue.slang
@@ -0,0 +1,15 @@
+//TEST:SIMPLE:
+
+// Passing an argument for an `out` parameter such
+// that implicit conversion would be required in
+// both directions.
+
+void a(out uint x)
+{
+	x = 0;
+}
+
+void b(int y)
+{
+	a(y);
+}