WIP: fix validation of passing enum as var_in_out

[leandrosansilva]

Ref #1518

TODO:

• implement unit tests
• check code generation

[ghaith]

Hello, thanks for the PR
I only added a suggestion to make sure only auto pointers are taken into consideration.
i would suggest tests to also make sure not only that IN_OUT enums are correct, but also that a REFERENCE TO enum in VAR_INPUT is correct, that an alias type to the enum is correct TYPE myAlias : myEnum END_TYPE and that a POINTER TO enum in VAR_INPUT does not actually allow the passing of enum values

[ghaith]

I would also check here that the pointer is an auto deref pointer, otherwise we start returing type variants for pointer types.

Suggested change

	DataTypeInformation::Pointer { name, inner_type_name, .. } => {
	DataTypeInformation::Pointer { name, inner_type_name, auto_deref: Some(_).. } => {

[leandrosansilva]

Where would you recommend adding the unit tests? I haven't looked very deep, but I haven't figured out how properly use the .snap based tests.

[ghaith]

the .snap files are snapshot tests, we create them using Cargo Insta the way this works is you write a test that should produce some kind of string, you can find examples in the codegen tests for that
What we usually have is something like

fn test() {
  let code = codegen("<plc code>");
  insta::assert_snapshot!(code, r#""#);
}

then if we run cargo test a snapshot file (.snap.new) will be generated. we then run cargo insta review and check if the snap file looks like what we expect, if it does we accept it and it will be added to the file.
If we skip the r#""# part in the assert_insta_snapshot macro, the result will be a .snap file.

In your case, i would recommend the first tests to go into index_tests.rs similar to pou_with_rescursive_type_fails and then you can add codegen tests to check if the argument is being passed correctly. The best place for codegen tests in this area would be the expression_generator tests.

Codegen tests are usually a bit cryptic, so what you can also do is first write some lit tests. These are integration test, just copy a .st file from the tests/lit/single file and change it to fit your test. any comment with //CHECK will be evaluated. You can use printf to output to the terminal, that's what CHECK will look for.
To use lit just run cargo xtask lit it will build the project, the standard functions and run all lit tests. You need to be in our dev container or have lit setup for that.
If you don't want to run lit locally you can also just compile and run the file by hand. You just need to include the printf function (under lit/utils) to your file and compile with --linker=cc or --linker=clang so libc gets linked with your binary.

[leandrosansilva]

Hi @ghaith,

FYI I've been quite busy with other projects and will be able able to resume working in this PR by late Oct/early Nov. In case there's rush on your side to finish it earlier, please feel free to take over the PR.