Cannot pass enum type as VAR_IN_OUT

[leandrosansilva]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
As of from the latest master (75585ec), 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.

[ghaith]

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.