From 2f782d403ae5729b6c93fbe92577ee01f7a8d608 Mon Sep 17 00:00:00 2001 From: Tim Foley Date: Fri, 20 Apr 2018 16:56:33 -0700 Subject: 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). --- tests/diagnostics/implicit-cast-lvalue.slang | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 tests/diagnostics/implicit-cast-lvalue.slang (limited to 'tests/diagnostics/implicit-cast-lvalue.slang') 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); +} -- cgit v1.2.3