Adds lower and upper bound function blocks

[franz-hoepfinger-4diac]

Introduces F_LOWER_BOUND and F_UPPER_BOUND XML configurations
to compute the lower and upper bounds of array dimensions.
Includes event inputs/outputs and variable declarations
for precise functionality.

[github-actions]

Test Results

  110 files  ±0    110 suites  ±0   1m 6s ⏱️ -4s
6 108 tests ±0  6 108 ✅ ±0  0 💤 ±0  0 ❌ ±0 
6 109 runs  ±0  6 109 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit ae9abcf. ± Comparison against base commit 0f31d38.

This pull request removes 29 and adds 11 tests. Note that renamed tests count towards both.

 
  *
  Multi-line comment
 Multi-line comment
 comment *)->
 comment */->
(*
*)
*/
…

org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 10: (*
 Multi-line comment
*)
s := "Hello   World!";
->s:="Hello   World!";
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 11: /*
 Multi-line comment
*/
s := "Hello   World!";
->s:="Hello   World!";
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 15: whitespace at the end 
->whitespace at the end
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 22: test unclosed multine comment
(*
  Multi-line comment
  *
->test unclosed multine comment
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 23: test unclosed multine comment
(*
  Multi-line comment

->test unclosed multine comment
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 24: test unclosed multine comment
/*
  Multi-line comment
  *
->test unclosed multine comment
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 25: test unclosed multine comment
/*
  Multi-line comment

->test unclosed multine comment
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 5: (* This is a multi-line 
 
 comment *)->
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 6: /* This is a multi-line 
 
 comment */->
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 8: // This is a single-line  
test->test
…

♻️ This comment has been updated with latest results.

[franz-hoepfinger-4diac]

ANY_INT as OUT seems unwise here. Better UINT ? right ?

[MartinMelikMerkumians]

As upper and lower array bounds could be either positive or negative and in general larger than the range of UINT, ANY_INT is the correct choice

[diplfranzhoepfinger]

As upper and lower array bounds could be either positive or negative and in general larger than the range of UINT, ANY_INT is the correct choice

I agree. now i have to learn, how do we handle a ANY_INT on the FORTE Level.

[mx990]

I believe these should be part of the iec61131-3 standard library, since both are defined in the IEC 61131-3 standard. I am not sure in which folder/package, however, since they are defined separately in section 6.5.3. Maybe selection would be a good fit?

[mx990]

Please rebase your branch to remove the unrelated commit.

[franz-hoepfinger-4diac]

@MartinMelikMerkumians should this stay in "selection" or move to "Array" ?

[MartinMelikMerkumians]

@MartinMelikMerkumians should this stay in "selection" or move to "Array" ?

I didn't want to challenge an already merged PR. If it was already agreed that it is selection, then it's ok for me. If its open for discussion, I would move it to a dedicated array functions package.

Any opinions @azoitl @mx990 ?

[diplfranzhoepfinger]

as we need to touch it anyhow, we could move it ! ?

[mx990]

After thinking some more on this, I also believe we should move it to a dedicated array package, since it does not really fit well in any existing one.

[azoitl]

I was a bit reluctant to change this but as the two blocks where anyhow not usable as the 4diac FORTE implementation is missing I also agree to move to the array package.

[franz-hoepfinger-4diac]

I was a bit reluctant to change this but as the two blocks where anyhow not usable as the 4diac FORTE implementation is missing I also agree to move to the array package.

Here you go:
#2373