Prototype for type inference IR pass

[radeusgd]

The first iteration of the type inference IR pass.

• Add a new IR pass and associated metadata for each expression.
  • The IR pass should be enabled by a feature flag; disabled by default.
    • This is because we want to be able to measure how it impacts performance, once Add benchmarks to runtime-compiler #8419 is integrated.
• Initialize it from the existing type ascriptions.
• Traverse the expression tree and try to thread through the type information
  • If the ascription is at the output (outer) expression of the function, we can record the return type of the function.
  • See how to record the arity of the functions.
  • Special logic for case of and if (as they need to be polymorphic to do any good, but the first iteration of the type system is not polymorphic).
  • For now, the type inference will rely on the 'functional' subset - i.e. applying to a function with checked arguments, or getting back a value from a function whose return type is known, yields known types.
  • In this iteration, no logic for o.member_methods, because that requires knowing the methods defined on a Type.
    • This is a larger endeavour and will be done later. We will need to extend BindingsMap.ResolvedType to know not only the constructors, but also methods on a type. Separate ticket to be created later.
• Displaying the inferred type info on the tree for debug purposes.
• Possibly reporting 'obvious' type errors if detected.
• See what is needed to report the types to the IDE.
  • The intention is to get compile-time type info for earlier loading of widgets.
  • This won't get us much without the o.member_methods - because 99% of widgets are on those, so it may make sense to do it later with the next iteration.

[enso-bot]

Radosław Waśko reports a new STANDUP for today (2023-12-27):

Progress: Working on type inference. Learning more about the IR, its state after various passes, how its transformed into Truffle Nodes and how we are handling applications. Did some notes on how we can approach resolving types. Creating a draft pass that deconstructs the IR. It should be finished by 2024-01-31.

Next Day: Next day I will be working on the same task. Create a simple metadata type for the inferred types. For now maybe just the type, but for later we will want more metadata (was it inferred or checked by signature etc). Implement simplest propagation scenarios (signature, block, force app). Look into resolving local names.

[enso-bot]

Radosław Waśko reports a new STANDUP for today (2023-12-28):

Progress: Created metadata type. Created a type-inference oriented type representation (not sure if a separate entity is needed but for now keeping it for simplicity). Storing inferred type for simple cases - first literals, then ascribed types. Resolving type expressions in ascriptions into a type representation. Propagating the types through FORCE nodes or blocks. Digging into how to correlate local variable names with their bindings to propagate types through bindings - WIP. Added more test cases for if, case-of, more complex type ascriptions (->, |, &). It should be finished by 2024-01-31.

Next Day: Next day I will be working on the same task. Continue digging into correlating local names with their bindings - this is the next low handing fruit for resolution.

[enso-bot]

Radosław Waśko reports a new STANDUP for the provided date (2023-12-29):

Progress: Added a CLI option to enable type checking when running Enso scripts. First type error being reported (currently as a warning) - early detection of a Not_Invokable error whenever a non-function is being called (e.g. 1 2). Added basic resolution of Atom Constructor types, allowing to infer the type of an atom when it is constructed. Adding test cases for that, especially with default arguments where there is some edge cases that curretnly do not yet work. It should be finished by 2024-01-31.

Next Day: Next day I will be working on the same task. Quick-fix for defaults args in constructors (disable inference if defaults are present, for now); later we will need to detect when defaults are forced or not - but that is a task for next steps. Continue work on resolving local bindings as that is the last important feature to have a reasonable PoC.

[radeusgd]

Stuff to do before first PR:

• fix spurious Not_Invokable warnings in constructr signatures like Vector Integer,
• fix persistance serialization errors,
• refactor: cleanup Type Inference logic, better manage common utils (package repository access, context)
• disable object type checks until conversions are resolved,
• check if I can infer type of self (delayed after Only allow the correct type to be used for self in the static method call syntax #8805 is implemented),
• fix logging,
• cleanup (move TypeCompatibility outside etc.)
• refactor: try avoiding duplicating the logic of IrToTruffle::processName within the inference - we should try to create some abstraction so that the logic is kept in just one place and accessible from both contexts
• ensure we can run Base_Tests with type check flag,
• test consistency: if a Not_Invokable warning is raised, check that it will actually happen at runtime.

[enso-bot]

Radosław Waśko reports a new STANDUP for yesterday (2024-01-18):

Progress: Prepared Enso_Secret in subdirectories PR with update_value. Adding some tests to type inference. Fixed the spurious Not_Invokable warning. Discussion on self type #8805. It should be finished by 2024-01-31.

Next Day: Next day I will be working on the same task. Some more sleanup. Next tasks

[enso-bot]

Radosław Waśko reports a new 🔴 DELAY for today (2024-03-01):

Summary: There is 45 days delay in implementation of the Prototype for type inference IR pass (#8590) task.
It will cause 4 days delay for the delivery of this weekly plan.

Delay Cause: For the last few weeks I was focusing on other things OR using the types time slot for finishing the related runtime self-type check (#8867), thus I was not spending the time on this ticket. Now I need to get back into it and remind myself where I was. It will still need a few iterations to finish the cleanups and get it ready.

Possible solutions: Not really applicable - we did prioritize other things so this obviously got on the backburner for that time. Ofc the delay is much greater because I'm just allocating 1 day a week to this, so it's kind-of-automatically 7x larger :)

[enso-bot]

Radosław Waśko reports a new STANDUP for the provided date (2024-03-01):

Progress: Updated the type inference PR to latest develop. Implemented toAbstract/toConcrete on BindingsMap.Type to prepare for serialization and restore, avoiding unnecessary references to IR that can be reconstructed. Removed BindingsMap.Type from TypeRepresentation (type metadata), also for better serialization. Trying to instead rely on bindings map to resolve that, but failing. TODO: see if it can be fixed, or take a different approach for this if not. It should be finished by 2024-03-16.

Next Day: Next day I will be working on the #9124 task. Start work on a Database datalink (Postgres)

[radeusgd]

Currently from Standard.Base import all fails with

Execution finished with an error: java.lang.IllegalStateException: Internal error: type signature contained _already resolved_ reference to type Standard.Base.Data.Json.Invalid_JSON, but now that type cannot be found in the bindings map.

• Investigate and try finding a smaller repro.

[enso-bot]

Radosław Waśko reports a new 🔴 DELAY for today (2024-03-15):

Summary: There is 20 days delay in implementation of the Prototype for type inference IR pass (#8590) task.
It will cause 0 days delay for the delivery of this weekly plan.

Delay Cause: Moving forward (got the common abstraction for name resolution, more tests), but still more work needed. Waiting for #9361 for serialization cycles support, still need to fix a bug where the typechecker crashes on Standard.Base (before it was only checked on minimal examples).

[enso-bot]

Radosław Waśko reports a new STANDUP for today (2024-03-15):

Progress: Added a test checking on example that a type-warning implies a runtime error. Implemented NameResolution - abstracting the common logic for resolving variable names both in compiler and in runtime (logic is common but the actual details differ). It should be finished by 2024-04-05.

Next Day: Next day I will be working on the #9324 task. Go back to datalink-as-symlink work - add symlink logic to our File-like types. Think how to do it in a sensible way.

[enso-bot]

Radosław Waśko reports a new STANDUP for yesterday (2024-03-27):

Progress: Reverted some changes and continued with an approach where I hold references to type description in TypeRepresentation. Refactoring how builtin types are resolved, made the inference more 'functional' (before it was too stateful). Figured out why a test was failing (imports not allowed in a compiler test as it did not have access to PackageRepository), moved the tests to get them working. It should be finished by 2024-04-05.

Next Day: Next day I will be working on the same task. Do a bit method shuffling cleanup and documentation, hopefully put up a PR. Start path-based Enso_File refactor.

[enso-bot]

Radosław Waśko reports a new STANDUP for yesterday (2024-03-28):

Progress: Cleanup, added docs - made the Types PR ready for review. Started work on Enso_File path-based refactor. It should be finished by 2024-04-05.

Next Day: Next day I will be working on the #9289 task. Continue the refactor.

[enso-bot]

Radosław Waśko reports a new 🔴 DELAY for today (2024-05-27):

Summary: There is 52 days delay in implementation of the Prototype for type inference IR pass (#8590) task.
It will cause 0 days delay for the delivery of this weekly plan.

Delay Cause: Waiting on support for cycles in serialization (#9361).

Possible solutions: N/A

[enso-bot]

Radosław Waśko reports a new STANDUP for the provided date (2024-05-24):

Progress: Investigated and fixed a few issues with loops in serialization. Implemented missing persistance for Types metadata. Got the PR in a state ready to merge (waiting for Monday as requested). It should be finished by 2024-05-27.

Next Day: Next day I will be working on the #9849 task. Work on UTF BOM heuristics.

[enso-bot]

Radosław Waśko reports a new STANDUP for today (2024-05-27):

Progress: Investigating one more test failure. Apparently more problems in serialization. Got into a bit of a rabbit hole trying to fix these. Upon request split off the serialization changes to a separate PR for clarity: #10101 It should be finished by 2024-05-27.

Next Day: Next day I will be working on the #9849 task. Work on UTF BOM heuristics.