lib: rename E to V in Map-related classes

Signed-off-by: Jean Privat <jean@pryen.org>
modelize_class: adapt MClass and MClassDef creation to new mparameters

Signed-off-by: Jean Privat <jean@pryen.org>
modelize_class: redefinition of generic classes do not need to repeat generic parameter declarations

Signed-off-by: Jean Privat <jean@pryen.org>
modelize_class: update resolve_mtype for new generic parameter names in the class

Signed-off-by: Jean Privat <jean@pryen.org>
src: update tools to new names in generic parameters

Signed-off-by: Jean Privat <jean@pryen.org>
separate_compiler: use the easier way to get a mparameter from a mclass

Signed-off-by: Jean Privat <jean@pryen.org>
engines: handle initializers with an arity!=1

Signed-off-by: Jean Privat <privat@pryen.org>
modelize: remove a useless local variable

Signed-off-by: Jean Privat <privat@pryen.org>
modelize: new annotation `autoinit` for manual setters

Signed-off-by: Jean Privat <privat@pryen.org>
tests: add base_init_autoinit.nit

Signed-off-by: Jean Privat <privat@pryen.org>
examples: update clock.nit with manual setter+autoinit

Signed-off-by: Jean Privat <privat@pryen.org>
misc/jenkins: fix checklicense.sh

* Correct documentation.
* Fix the regular expression for the sought comment.

Signed-off-by: Jean-Christophe Beaupré <jcbrinfo@users.noreply.github.com>
compiler: compile_dir can be anywhere

Signed-off-by: Jean Privat <jean@pryen.org>
tests: add base_gen_redef.nit

Signed-off-by: Jean Privat <jean@pryen.org>
Merge: Fix generic parameter names

Since the beginning of Nit and class refinement, formal parameter names were attached to local-classes (MClassDef). So giving the ability to use different names in various class refinements.
This was done in an analogous way with parameters in methods since one can change their names in redefinitions or methods.

Nowadays, I think it is a nonoptimal idea since this renaming ability is unused, worse it is considered bad since it makes code more complex to read: one do not want to have distinct vocabulary for the same class but in distinct modules.

Moreover, having parameters attached to the class but names attached to the classdef cause some meta-model nightmares and a workaround was to internally name parameters with their rank in the class.
But nobody liked error message like `got Foo#0 but expected Bar#2`

A last issue is that, for a dynamic type system point of view, the formal types can be exposed as object-oriented-services. For instance, in potential construction like `if x isa y.T then ...`, where `T` is a formal type defined in the static class of `y`, and that will be resolved at runtime.
Thus, it is a bad idea that names of services can vary through refinement.

Therefore, this PR moves the name of generic formal parameters in `MParameterType`, kill the ugly `MClassDef::parameter_names`, rationalize `MClass` and `MClassDef` construction, and update all the client code.

This PR gives also two bonuses:

* `name` and `to_s` in `MParameterType` make sense so type-related error messages are more readable.
* Since the names of formal parameters become invariant in refinements, their declaration become optional:
~~~.nit
redef class Array # no E declared here
   fun pushshift(e: E):E do # but used here
      add(e)
      return shift
   end
end
~~~

Pull-Request: #781
Reviewed-by: Alexandre Terrasa <alexandre@moz-code.org>
Reviewed-by: Alexis Laferrière <alexis.laf@xymus.net>
Merge: misc/jenkins: fix checklicense.sh

* Correct documentation.
* Fix the regular expression for the sought comment.

Fixes #780.

Signed-off-by: Jean-Christophe Beaupré <jcbrinfo@users.noreply.github.com>

Pull-Request: #786
Reviewed-by: Jean Privat <jean@pryen.org>
Merge: new annotation for manual setter `autoinit`

Sometime, automatic setters are not suitable and manual ones should be used.
Nit, especially since annotations (#601 and #604), has a simple way to have attributes and manual setters.

~~~niy
class A
   var foo: String is private writable(private_set_foo)
   fun foo=(v: String) do ...
end
~~~

However, with new constructor, it is the `private_set_foo` method that is used as initializer during the instantiation.

~~~nit
var a = new A("toto") # is in fact:
# a = alloc-instance(A)
# a.private_set_foo("toto")
# a.init
~~~

One may want to manually promote some setters as initializers, it is the job of the proposed `autoinit` annotation.

~~~nit
class B
   var foo: String is private writable(private_set_foo), noinit
   fun foo=(v: String) is autoinit do ...
end

var b = new B("toto") # is in fact:
# B = alloc-instance(B)
# b.foo=("toto")
# b.init
~~~

Bonus: in fact, this works for any method, even when they have more than one parameter. See the modification of the clock example that now use new constructors with a manually-set auto-initializer.

Pull-Request: #787
Reviewed-by: Lucas Bajolet <r4pass@hotmail.com>
Reviewed-by: Alexandre Terrasa <alexandre@moz-code.org>
Merge: compiler: compile_dir can be anywhere

Fix an old TODO. Now you can compile where you want and stop having a bunch of fat .nit_compile directories everywhere.

~~~sh
$ nitg --compile-dir /tmp/nit_compile examples/hello_word.nit
~~~

Pull-Request: #789
Reviewed-by: Alexandre Terrasa <alexandre@moz-code.org>
Reviewed-by: Alexis Laferrière <alexis.laf@xymus.net>