The dependency on the clock was lost when the enum is translated into
an integer (because some expression were still refering to the enum type).

The fix was to index VarMap.t by string instead of Soc.var_expr in ActionsDeps.

Remove a lot of warnings (considered as errors by dune).

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.

BTW, fonctionalise the corresponding non-debug code.

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

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)

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

Also, use rdbg instead of lurettetop to run the test.

nb : i have changed the var name in the generated nodes, which was a bad idea
(=painful to get it rigth again).

by
- remove duplication (add a profile_info function ine Lv6Verbose
- be more efficient (computing Sys.time only when necessary
- control the time-profiling printing via the -dbg flag "profile", and
  not the verbosity level

I was re-implementing an inneficient topological sort there (using a
linear list instead of logarithmic map). I win 1s on tri.ec (~8000
locals).

Ditto for Misc and Compile

Fix the bug detected in the previous commit where type instance were not propagated in package obtained from a model instance.

More precisely, issuing an "exit 2" is not enough for the
should_work proc in test/site.exp to state that the test fails.

That fix revealed a certain number of bad programs.
Some were not really wrong ; there were just not respecting the
naming convention used to automated the test (i.e., main node name =
file name).

It also releaved a real bug due to the fact that type
instanciatiation is not propagated during model instanciatiation,
where creates a loop between (Lic2soc.process_node and
Lic2soc.soc_of_node). Indeed it searches in the soc the table for an
abstract profile.

Actually, that was the default behavior. Now the default behavior is
to generate loops for iterators.

nb : with -2ch, loops are still always inlined

e.g., for arrays.

No test actually catches this bug.

when calling soc.

Do not work all the times (eg, with arrays it generates C code that
does not compile). cf next changes.

Indeed it is possible when each branch of the ite updates no memory.
This is done in the new L2lOptimIte module.

For the time being, it does detect when the node has no memory. It
only looks at the declaration: nodes have memory, and not functions.

I should infer that information and raise warnings or errors if what
I infer is not compatible with waht is declared (will come later).

Also split ActionsDep into ActionsDep and Action.

Also fix a bug in L2lsplit where deeply nested (>2) merge were not
splitted.

Report by willie (cf mail of 8/10/2014 to get the file)

file:/tmp/modes3x2.lus

lus2lic -esa -en -2c /tmp/modes3x2.lus -n modes3x2

But it gives an error of:
Error. in file "/mnt/A/wsept/modes3x2_pre_orig_lus2lic_en_esa/modes3x2.lus",
line 74, col 8 to 8, token '#': only one operator per equation is allowed
(v04_0, v04_1).

Which is the line:
assert #(on_off, toggle);

-----------------------------------------------------------------

Actually, refuse programs that uses "#" or "nor" run with -esa and
-2c|-exec

That means that willie program is now rejected.

Nevertheless, that change migth fix some other programs (that uses
arrays, and used with -esa and -exec or -2c).

Also fix a bug in Lic2soc.make_e2a_elt where some deps and some
actions were lost. Actually, this bug ought to be triggered only with
nested calls. So this affects only programs executed via the
-knc/-keep-nested-calls option. and -2c is not supposed to work in
conjunction with -knc ! Hence this fix does not fix anything. But
still it fixes potentially future code if I (or someone else) decide
to handle nested calls in the lic one day.

Indeed, computing the dependencies and choosing an order for actions
(that may optimize test openning in the near futurea) are 2 different
things.

Also provide a default version of those macros using memcpy.

is the clock of the quicker clock among its inputs, not among its output !

nb : the -exec mode was working because I did not use the generated soc,
which was completely wrong.

Note that to do that, I have modified the CURRENT variant of
Lic.val_exp, to attach it the clock the current holds on. Indeed, the
clock is mandatory to generated correct code...

In an ideal world, this clock information may have explicitely been
set by the user ("current(clk_of_X,X)" instead of "current(X)"), but
for historical reason, it is not the case.

Hence, this information is added as soon as it is available, namely,
during clock checking.

and -2c).  Indeed, the l2lExpandArrays sometime transforms a
Lic.var_exp ve into TUPLE[ve].

# of unexpected failures	101->109

but actually, some new test passes causes several other failing test
to be tried, so it is not really a regression.

where I've removed the handling of polymorphism.

For instance,
  node toto = map<<Lustre::if,  N>>(x, a, b);
is rejected.

The problem with this change is that we now also reject equations such as
   res = map<<+,  N>>(x, a, b);

which could be avoided. Probably L2lRmPoly does its job partially.

nb:  unexpected failures	144->143