Thu, 19 Dec 2013 19:38:29 +0000Fix bug: allow use, as lvalues, structures/arrays inside FBs (e.g. fb1.struct1.r := 33.3).
Mario de Sousa <msousa@fe.up.pt> [Thu, 19 Dec 2013 19:38:29 +0000] rev 852
Fix bug: allow use, as lvalues, structures/arrays inside FBs (e.g. fb1.struct1.r := 33.3).

Wed, 18 Dec 2013 18:41:05 +0000Fix bug/issue #33 (correctly access struct/array variables declared inside a FB -> r:=FB1.FB2.struct1.array1[3] )
Mario de Sousa <msousa@fe.up.pt> [Wed, 18 Dec 2013 18:41:05 +0000] rev 851
Fix bug/issue #33 (correctly access struct/array variables declared inside a FB -> r:=FB1.FB2.struct1.array1[3] )

Sat, 07 Sep 2013 22:08:09 +0100Add assertion suggested by Manuele.
Mario de Sousa <msousa@fe.up.pt> [Sat, 07 Sep 2013 22:08:09 +0100] rev 850
Add assertion suggested by Manuele.

Fri, 23 Aug 2013 15:13:11 +0100merge
mjsousa [Fri, 23 Aug 2013 15:13:11 +0100] rev 849
merge

Fri, 23 Aug 2013 12:33:12 +0100Use get_datatype_info_c::is_type_valid() to determine datatype validity
mjsousa [Fri, 23 Aug 2013 12:33:12 +0100] rev 848
Use get_datatype_info_c::is_type_valid() to determine datatype validity
(some datatype bugs in source code were going unreported!)

Fri, 23 Aug 2013 12:06:08 +0100Recursively check the datatype compatibility of values/expressions passed in function/FB invocations.
mjsousa [Fri, 23 Aug 2013 12:06:08 +0100] rev 847
Recursively check the datatype compatibility of values/expressions passed in function/FB invocations.

Fri, 23 Aug 2013 09:34:04 +0100Change error message text so as to become more suitable to where they might occur in the source code.
mjs [Fri, 23 Aug 2013 09:34:04 +0100] rev 846
Change error message text so as to become more suitable to where they might occur in the source code.

Thu, 22 Aug 2013 19:12:10 +0100Add code to check if an IN_OUT variable is being passed an IL list in formal IL FB/function invocations.
mjsousa [Thu, 22 Aug 2013 19:12:10 +0100] rev 845
Add code to check if an IN_OUT variable is being passed an IL list in formal IL FB/function invocations.

Thu, 22 Aug 2013 18:50:43 +0100Generate correct error message when encountering IL lists embedded in IL formal invocations.
mjsousa [Thu, 22 Aug 2013 18:50:43 +0100] rev 844
Generate correct error message when encountering IL lists embedded in IL formal invocations.

Thu, 22 Aug 2013 16:53:17 +0100Fill in the 'datatype' anotation in the identifiers of symbolic variables.
mjsousa [Thu, 22 Aug 2013 16:53:17 +0100] rev 843
Fill in the 'datatype' anotation in the identifiers of symbolic variables.
(even though currently it is not being used).

Thu, 22 Aug 2013 16:51:22 +0100Fix C code generation of FB invocation in IL.
mjsousa [Thu, 22 Aug 2013 16:51:22 +0100] rev 842
Fix C code generation of FB invocation in IL.

Thu, 22 Aug 2013 07:39:33 +0100Fix detection of datatype errors on IL conditional flow control operators (JMPC, RETC, ...)
mjsousa [Thu, 22 Aug 2013 07:39:33 +0100] rev 841
Fix detection of datatype errors on IL conditional flow control operators (JMPC, RETC, ...)

Wed, 21 Aug 2013 21:56:41 +0100Allow array_dimension_iterator to accept an array_spec_init_c.
mjsousa [Wed, 21 Aug 2013 21:56:41 +0100] rev 840
Allow array_dimension_iterator to accept an array_spec_init_c.
Fixes bug activated by generating C code from IL code containing array variables.

Wed, 21 Aug 2013 21:34:43 +0100Small code cleanup (move common code to a function)
mjsousa [Wed, 21 Aug 2013 21:34:43 +0100] rev 839
Small code cleanup (move common code to a function)

Wed, 21 Aug 2013 21:26:55 +0100Fix datatype analysis of conditional IL operators (CALC, CALCN, RETC, RETCN, JMPC, JMPCN, S and R)
mjsousa [Wed, 21 Aug 2013 21:26:55 +0100] rev 838
Fix datatype analysis of conditional IL operators (CALC, CALCN, RETC, RETCN, JMPC, JMPCN, S and R)

Wed, 21 Aug 2013 21:14:50 +0100Fix datatype analyses of S and R IL operators.
mjsousa [Wed, 21 Aug 2013 21:14:50 +0100] rev 837
Fix datatype analyses of S and R IL operators.

Wed, 21 Aug 2013 16:08:50 +0100make sure all IL operands are narrowed (datatype checking algorithm)
mjsousa [Wed, 21 Aug 2013 16:08:50 +0100] rev 836
make sure all IL operands are narrowed (datatype checking algorithm)

Wed, 21 Aug 2013 16:06:43 +0100cosmetic change only - fix code alignment.
mjsousa [Wed, 21 Aug 2013 16:06:43 +0100] rev 835
cosmetic change only - fix code alignment.

Tue, 20 Aug 2013 11:15:40 +0100Add support for FB call semantics of 'S' and 'R' IL operators!
mjsousa [Tue, 20 Aug 2013 11:15:40 +0100] rev 834
Add support for FB call semantics of 'S' and 'R' IL operators!
Remove segfaults when analysing buggy IL code (IL operators with no operands).

Tue, 20 Aug 2013 11:11:09 +0100Stop lvalue check from segfaulting when coming across buggy IL code (IL operator with no operand!)
mjsousa [Tue, 20 Aug 2013 11:11:09 +0100] rev 833
Stop lvalue check from segfaulting when coming across buggy IL code (IL operator with no operand!)

Tue, 20 Aug 2013 11:08:15 +0100Allow get_datatype_info_c to be called with NULL parameters.
mjsousa [Tue, 20 Aug 2013 11:08:15 +0100] rev 832
Allow get_datatype_info_c to be called with NULL parameters.

Thu, 15 Aug 2013 11:24:54 +0100Do lvalue check of function output parameters (since they may contain expressions inside array subscripts!)
mjsousa [Thu, 15 Aug 2013 11:24:54 +0100] rev 831
Do lvalue check of function output parameters (since they may contain expressions inside array subscripts!)

Sat, 10 Aug 2013 09:10:06 +0100Handle buggy source code gracefully (do not bork when non-array variable is used as an array. e.g: int_var[42]:= 33)
mjsousa [Sat, 10 Aug 2013 09:10:06 +0100] rev 830
Handle buggy source code gracefully (do not bork when non-array variable is used as an array. e.g: int_var[42]:= 33)

Wed, 07 Aug 2013 10:34:57 +0100Delete debugging messages left in by mistake.
mjsousa [Wed, 07 Aug 2013 10:34:57 +0100] rev 829
Delete debugging messages left in by mistake.