Prof of concept for lazy semantic analysis of the bodies of methods.
It means that the bodies of methods can be analysed only at the first request of the associated AST node.
It is disabled by default (see bellow) but can be enabled with --sloppy
It may improves the speed of some tools, especially the interpreter (and the VM).
For `nit hello_world.nit`.
before: 0m0.260s
after (lazy): 0m0.188s
explication: `standard` remains mostly unanalysed
For `nit nit.nit`
before: 0m1.824s
after: 0m1.060s
explication: `src/` and libs remain mostly unanalysed
For `nit nit.nit ../tests/base_simple3.nit`
before: 0m3.868s
after: 0m3.464s
explication: still some parts of `src/` and libs not analysed
However. there is some issues that remains
* `nitc` will crash with it because coloration is done before `super` are collected
* there is not always a gain, most tools need the full analysis of each method, thus doing the analysis in a lazy way can only degrade the performances.
* this could allow the interpreter to happily execute (or the compiler to compile) statically invalid programs. Eg. a bad identifier in a unused method will be undetected with the lazy approach.
* testing in `tests/` will be difficult because the error messages will change (see previous point)
Pull-Request: #1064
Reviewed-by: Alexis Laferrière <alexis.laf@xymus.net>
end
if not found then fatal_error(null, "Error: no phase named `{v}`. Use `list` to list all phases.")
end
+
+ if opt_sloppy.value then semantize_is_lazy = true
end
- # The list of phases in the order to run them
+ # The list of registered phases in the application order.
- fun phases_list: Sequence[Phase]
- do
+ var phases_list: Sequence[Phase] is lazy do
var phases = self.phases.to_a
self.phases.sort(phases)
return phases