mirror of
https://github.com/enso-org/enso.git
synced 2024-12-23 18:34:03 +03:00
4bbabc00be
This PR replaces hard-coded `@Builtin_Method` and `@Builtin_Type` nodes in Builtins with an automated solution that a) collects metadata from such annotations b) generates `BuiltinTypes` c) registers builtin methods with corresponding constructors. The main differences are: 1) The owner of the builtin method does not necessarily have to be a builtin type 2) You can now mix regular methods and builtin ones in stdlib 3) No need to keep track of builtin methods and types in various places and register them by hand (a source of many typos or omissions as it found during the process of this PR) Related to #181497846 Benchmarks also execute within the margin of error. ### Important Notes The PR got a bit large over time as I was moving various builtin types and finding various corner cases. Most of the changes however are rather simple c&p from Builtins.enso to the corresponding stdlib module. Here is the list of the most crucial updates: - `engine/runtime/src/main/java/org/enso/interpreter/runtime/builtin/Builtins.java` - the core of the changes. We no longer register individual builtin constructors and their methods by hand. Instead, the information about those is read from 2 metadata files generated by annotation processors. When the builtin method is encountered in stdlib, we do not ignore the method. Instead we lookup it up in the list of registered functions (see `getBuiltinFunction` and `IrToTruffle`) - `engine/runtime/src/main/java/org/enso/interpreter/runtime/callable/atom/AtomConstructor.java` has now information whether it corresponds to the builtin type or not. - `engine/runtime/src/main/scala/org/enso/compiler/codegen/RuntimeStubsGenerator.scala` - when runtime stubs generator encounters a builtin type, based on the @Builtin_Type annotation, it looks up an existing constructor for it and registers it in the provided scope, rather than creating a new one. The scope of the constructor is also changed to the one coming from stdlib, while ensuring that synthetic methods (for fields) also get assigned correctly - `engine/runtime/src/main/scala/org/enso/compiler/codegen/IrToTruffle.scala` - when a builtin method is encountered in stdlib we don't generate a new function node for it, instead we look it up in the list of registered builtin methods. Note that Integer and Number present a bit of a challenge because they list a whole bunch of methods that don't have a corresponding method (instead delegating to small/big integer implementations). During the translation new atom constructors get initialized but we don't want to do it for builtins which have gone through the process earlier, hence the exception - `lib/scala/interpreter-dsl/src/main/java/org/enso/interpreter/dsl/MethodProcessor.java` - @Builtin_Method processor not only generates the actual code fpr nodes but also collects and writes the info about them (name, class, params) to a metadata file that is read during builtins initialization - `lib/scala/interpreter-dsl/src/main/java/org/enso/interpreter/dsl/MethodProcessor.java` - @Builtin_Method processor no longer generates only (root) nodes but also collects and writes the info about them (name, class, params) to a metadata file that is read during builtins initialization - `lib/scala/interpreter-dsl/src/main/java/org/enso/interpreter/dsl/TypeProcessor.java` - Similar to MethodProcessor but handles @Builtin_Type annotations. It doesn't, **yet**, generate any builtin objects. It also collects the names, as present in stdlib, if any, so that we can generate the names automatically (see generated `types/ConstantsGen.java`) - `engine/runtime/src/main/java/org/enso/interpreter/node/expression/builtin` - various classes annotated with @BuiltinType to ensure that the atom constructor is always properly registered for the builitn. Note that in order to support types fields in those, annotation takes optional `params` parameter (comma separated). - `engine/runtime/src/bench/scala/org/enso/interpreter/bench/fixtures/semantic/AtomFixtures.scala` - drop manual creation of test list which seemed to be a relict of the old design |
||
|---|---|---|
| .. | ||
| src | ||
| README.md | ||
Enso Language Server
The Enso Language Server is responsibile for providing a remote-communication protocol for the runtime, exposing many of its features to the users. In addition it provides the backing service for much of the IDE functionality associated with the language. It encompasses the following functionality:
- Introspection Services: Giving clients the ability to observe information about their running code including values, types, profiling information, and debugging.
- Code Execution: The ability for clients to execute arbitrary Enso code in arbitrary scopes. This can be used in conjunction with the above to provide a REPL with an integrated debugger.
- Code Completion: Sophisticated completion functionality that refines suggestions intelligently based on context.
- Node Management: Tracking and providing the language server's internal node representation of the Enso program.
- Code Analysis: Analysis functionality for Enso code (e.g. find usages, jump-to-definition, and so on).
- Refactoring: Refactoring functionality for Enso code (e.g. rename, move, extract, and so on).
- Type Interactions: Features for type-driven-development that allow users to interact with the types of their programs.