By not catching errors, rdbg and (thus) lurette were silently do nothing
in presence of errors in Lustre files.

The idea is to be able to take into account clock in node profiles
when generating the main simulation loop, and to avoid to read inputs
that are not present.

add and install an alias to lus2lic name lv6.

lus2lic --gen-autotest now overrides existing _oracle*.lus and _env*.lut files

The generated code for tests on boolean output was wrong. Indeed, it
was generating

  if (o1 == _true) {

instead of

  if (*o1 == _true) {

nb : a warning was emited

Add code to support empty arrays (not yet working)

BTW, fix iterator handling which was not working from SocExecDbg

BTW, fonctionalise the corresponding non-debug code.

+ fix a (invisible) bug in lic2soc: the same action was generated twice.

Basically, I have added the missing fields

Basically, I have added the missing fields

It was also the case in L2lRemovingAlias, but the bug in L2lExpandNode was
happening before.

nb: the 2 tests that now pass pass for other reasons (because of a change in
rdbg 1.108)

I've done the same fix in LicDump actually to be sure (more parenthesis can't hurt).

fix carligths.lus which was badly initialized

And it is now done only by Lic2soc (L2lCheckLoops is not used anymore)

Also, during this change, I was bitten again by the « "__" versus "::" in ident
names » problem again.

The core of this problem is due to the fact that I use LicDump both for
(1) dealing with internal ident names
(2) generating lustre files

Because of (2), ident names may depend on the ec or the v4 option. hence, internal
names were sometimes translated with "__" instead of "::".

To (try to) fix that, I've added a boolean flag to all "to_string" functions that
states whether the function is used for internal purposes, or for generating lustre
files.

It was quite a boring change, that triggered other problems, that I've fixed
in this (too long) commit :
 - -esa should force -en, otherwise bad things happen (-esa is used for -ec anyway)
 - in -esa mode, #/nor inputs tuples of bool, not arrays
 - fix the list of predi op that returns a type different that its arg (SocPredef)

It is useless (I hope) and it sometimes creates combinatory loops.

Indeed,
   x=y iff memcmp(x,y) == 0
not
   x=y iff memcmp(x,y) != 0
!

But actually, it is possible to have node without output, so expression
without output clock is perfrectly possible, as in the following example :

node h(x : bool) returns ();
 var h : bool;
let
  h = false fby (not x);
tel

node f(x : bool) returns (y: bool);
var
  u:bool;
let
  y,u = (false, h(true), true) fby (true, x, h(false));
tel

Also, -eeb is now the default when using -ec.

It was generetaing wrong code in conjunction with -ec.

In particular, it was generating n-any "and" instead of binary "and".

Also, I needed (in L2LExpandEnum) to generated a Lic.ARRAY of const
instead of a Lic.Array_const_eff so that LicDump properly generated
ec code.

To do that, I have created a new dedicated module L2lExpandEnum, that
actually also deals with -eei (which was probably wrong, even if I
have not counter-exemple).

Use 1-hot encoding instead of log-encoding

I've fixed a bug in L2lExpandArrays that occurs on equation such as
  some_bool = (some_array1 = some_array2);

Also, I've rewritten Lv6Compile for more readability

Remove duplicated code when using SocMap.find and co

I've fixed that using memcmp, which should be fine since compared elements
are of the same types.

+ add a test that reveal a pb in the generated C code in lustre programs
that perform equalities on arrays.

Indeed, expressions such as "3.0-42.5" caused a syntax error, as the unary minus
of real constant was in hard in the lexer.  "3.0- 42.5" worked, but still.

The problem then was that LicEvalConst refused to eval "- 3.14", that was
parsed directly as a constant, and that is now a call to the unary minus.
I've added specific code to handle this case.