Cannot pass enum type as VAR_IN_OUT
Describe the bug A clear and concise description of what the bug is.
To Reproduce As of from the latest master (75585eca8551248ec0fd4ca7d5099b2b911e93b8), try compiling the following program:
(* program.st *)
TYPE OptResult : (
OPT_RESULT_NONE,
OPT_RESULT_SUCCESS,
OPT_RESULT_FAILURE
);
END_TYPE
FUNCTION foo
VAR_IN_OUT
result : OptResult;
END_VAR
result := OptResult#OPT_RESULT_FAILURE;
END_FUNCTION
FUNCTION baz
VAR
return_val : OptResult := OptResult#OPT_RESULT_NONE;
END_VAR
foo(result := return_val); (* This binding should work, but at the moment it does not *)
END_FUNCTION
PROGRAM bar
baz();
END_PROGRAM
You will get the following error:
error[E040]: Invalid enum value `return_val` for `OptResult`
┌─ /blah/program.st:20:17
│
2 │ TYPE OptResult : (
│ --------- see also
·
20 │ foo(result := return_val); (* This binding should work, but at the moment it does not *)
│ ^^^^^^^^^^ Invalid enum value `return_val` for `OptResult`
Compilation aborted due to critical errors.
Hint: You can use `plc explain <ErrorCode>` for more information
Expected behavior
I would expect the compiler to understand I want to bind the variable return_val to the VAR_IN_OUT result, instead of assuming return_val to the the literal value for an enum.
Additional context I have an existing codebase that builds well using an existing PLC industrial compiler, where such construction is widely used and working well. I am not sure on what the standard says, but such construction sounds sensible and I cannot imagine what would forbid it.
I've been hacking the rusty codebase recently and can work on a fix, but first I'd like to know whether such behaviour is expected or this is really a bug.
Hello, this is definitely a bug and was on our radar very recently (Internal tracker, seems we forgot to move it to the github issues). In fact I wanted to start working on this by next week :) If you have something going already I'll be happy to review a PR.