lib/standard: Move top-level methods in `file` really to the top level.

Signed-off-by: Jean Privat <jean@pryen.org>
modelize_property: always check `redef`
With a lesser strict version for the implicit main.

I am not really sure why the original code was this.

Signed-off-by: Jean Privat <jean@pryen.org>
modelize_property: remove double check of duplicate property

One is enough. Moreover, the removed-one is buggy since only AMethPropdef
is checked.

Signed-off-by: Jean Privat <jean@pryen.org>
modelize_property: improve error message for property already defined

Signed-off-by: Jean Privat <jean@pryen.org>
tests: update for new error message on already defined property

Signed-off-by: Jean Privat <jean@pryen.org>
model: add `MMethod::is_toplevel`

Documentation will like to have such an information easily available.

Signed-off-by: Jean Privat <jean@pryen.org>
modelize_property: top_level methods can only redefine and be redefined by top_level methods

Signed-off-by: Jean Privat <jean@pryen.org>
tests: add tests for top-level redefinitions

Signed-off-by: Jean Privat <jean@pryen.org>
typing: `interator` in for is correclty set on self

Signed-off-by: Jean Privat <jean@pryen.org>
tests: update error messages related to `iterator` in for,

Signed-off-by: Jean Privat <jean@pryen.org>
Merge: Distinguish top-level methods

The point of the PR is the commit that adds `MMethod::is_toplevel` to distinguish methods defined at the top-level of a module, with those defined in an explicit refinement of Object.

Such an information could be used by documentation tool to filter methods.

A following commit use the information to enforce that top-level methods redefine and are redefined only by top-level methods (by refinement). However, the rules in the model remains unchanged and there is no other use of the `is_toplevel` information in tools or execution engines.

The bunch of first commits are used to clean and improve the check of redefinitions used latter.

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

offers the service `native_array_instance` in all compilation engines

Signed-off-by: Jean Privat <jean@pryen.org>
erasure_compiler: remove redefinition of `array_instance`

the inherited implementation from the separate compiler is
enough now that `native_array_instance` is correctly implemented.

Signed-off-by: Jean Privat <jean@pryen.org>
parser: accept intern methods at top-level

This modification does not need a special handling in the model or engines.

Signed-off-by: Jean Privat <jean@pryen.org>
parser: introduce intern `new` constructors (factories)

They are correctly modeled and typed but engines does not how to deal with them.

Signed-off-by: Jean Privat <jean@pryen.org>
parser: regenerate file for improved intern methods

Signed-off-by: Jean Privat <jean@pryen.org>
compiler: special handling of `new NativeArray`

Signed-off-by: Jean Privat <jean@pryen.org>
compiler: accept intern `new` constructors (factories)

Signed-off-by: Jean Privat <jean@pryen.org>
java FFI: display a clean error when java module is not imported

Signed-off-by: Alexis Laferrière <alexis.laf@xymus.net>
compiler: Accepts `new` constructor on non pointer-based class (eg. NativeString)

Just use with a placebo receiver like in other cases.

Signed-off-by: Jean Privat <jean@pryen.org>