nb: still does not work for nested iterators

close #8

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

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 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

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

The bug was appearing a node was called on a non base clock that was
existing in the called nodes (name clash). Typically, it occurs on
recursive node called on some non-trivial clocks.

Also, use maps instead of list to hold the substitution between
params and args.

More precisely, transforms equations of the form

   y = x when Toto(c);

into

   x when Toto_c ;
   Toto_c=Toto(c);

('::' vs '__')

soc2c -2cw7: use mkff+fixffx+arm.looploc to fix extern lib calls.

Ditto for Misc and Compile

Indeed, having two different mechanisms is bad.

In the end, I've kept mine (and not the one of Pascal), because the
it was depending on LicPrg.t, which was creating a circular dep
(which could of course be fixed, but I am lazy).

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).

nb: bad timings is due to NFS and pavé that is dying.

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].

It generates C code that compile on at least one example.

The test now runs in 150s (versus 417s)

[...] for some reasons, i cannot reproduce the 150s !!!

(to be kind with data plotters).

(1) equations such as
 (x,y,z)=[0,0,0];
were generated with -en unless -ec was specified.

I've fixed that by always breaking tuples, even when global_opt.ec
is false (this condition was strange anyway).

(2) During node expansion, I create a fresh variable for each local
var in the expanded node, but old var names were still appering in
clock expression

indeed, consider that example :
var
  c:bool;
  x when c :bool;

I was generating something equivalent to

var
  c_fresh:bool;
  x_fresh when c :bool;

bou... Of course, it was working because in -ec mode, I need to
remove clock annotation when declaring local variables, which was
hidding the problem.

nb : because I've change test_lus2lic_no_node to use -lv4 instead of
-ec to generate the lustre oracle, which exposes new pbs (cf above).

(3) When expanding a node on the base clock with arguments on another
clock, I was not propagating that information (let's keep the
finger-crossed and hope the current fix is complete).

nb : the number of failing test cases is the same (5 new pass, but 5
new fail!!), but it actually is a progression. Indeed, the new test
failures ares due to the fact that this current change fixes a
problem that expose yet another one!

Actually, the newly exposed bug is not in the compliler, but in the
oracle I generate via the --auto-test option ; indeed, for testing
nodes which not all interface variables are one the base clock, I
should generate oracle that do take them into account.

As far as ldbg is concerned, it only traces the toplevel node, at
call event.

Note that I needed to rename quite a lot of modules to avoid name clashes
between lus2lic.a and ltop.

I've also merged the Verbose module with the one of Lutin so that
they can be shared (there were sharing 95% already).

Also Merge the Global and the MainArg module as they were
(bizzarely) both handling command args options.

1) At the Lic level, there's no reason to distinguish betwenn node
calls, and predef node calls. Indeed it makes things simpler and more
homogeneous afterwards.

2) int strings are only converted when necessary (constant evaluation).

3) const are handled directly under Lic.by_pos_op instead of being under
   PREDEF_CALL, which make things easier and more logical.

Pascal prepared « the field » for that change.

The only culprit was the one in unifyClock.ml::249, but
I've lazyfied most of the non-trivial verbose call.

The 2 remaining unresolved testq that were timeout-ing now pass in a few ms...

The whole non-reg test time has been divided by more than 2!

nb : do not work for lv4/ec mode

Also fix some bugs in DumpLic when printing condact in other modes.