Merge Ezno runtime definitions with existing TS definition files

[kaleidawave]

Currently the checker is built around definitions from this file

https://github.com/kaleidawave/ezno/blob/main/checker/definitions/overrides.d.ts

To support more of the runtime (as highlighted in #118), the checker should be able to use definitions from the TypeScript repository (such as es5.d.ts) to provide the same type coverage. As can be seen in overrides.d.ts, Ezno has some extended definitions to provide better information to the checker. What should be done is to create a tool (code mod / code modification) (similar to code_blocks_to_script.rs that parses es5.d.ts but selectively overwrites with definitions in overrides.d.ts to produce a final definition file build.

[!WARNING]

120 (increasing the count of types and layout) is really needed to support the scale of es5.d.ts

[kaleidawave]

Some thinking on es5.d.ts

Also I don't quite know the status of how much of es5.d.ts Ezno currently supports. For example the features:

• [x] rest parameters
• [ ] optional parameters (I think but, no tests?)
• [ ] overloading (TODO write up issue)
• [ ] Mapped types (TODO issues for the last two maybe)
  • [x] Record
  • [ ] Pick
  • [ ] Omit
• [ ] readonly properties
• [ ] Symbols

Taking a flick through some things

• Not all overloading needs to be considered
• Some helpers like Awaited might not be needed initially (or implemented in other ways)
• what to do for intristic types
• *X* and *X*Constructor types can be merged (as the definitions now use classes)
• Things like Math need @Constant decorators on most methods (but Math.random() needs @InputOutput
• Console needs @InputOutput on most methods

[CharlesTaylor7]

What does the @Constant decorator mean? Does it mean that the function can be safely run at compile time?

[kaleidawave]

@Constant marks a function or method as having its effect as FunctionEffect::Constant which yes principally means its return type is fixed and can be calculated at compile time IF its inputs are literals. This calculating is done in the checker/src/features/constant_functions.rs file.

For example here Math.sqrt is a function with constant effects under identifier sqrt https://github.com/kaleidawave/ezno/blob/24e35b98da5a6c705be3cce7eb56dc17bfcb32a4/checker/definitions/overrides.d.ts#L129-L130 and if its input are known and literal (for example 16), then it can be calculated in Rust https://github.com/kaleidawave/ezno/blob/24e35b98da5a6c705be3cce7eb56dc17bfcb32a4/checker/src/features/constant_functions.rs#L83 which is how you get the errors here.

It is a slightly bit gimmicky, it can catch against some always true cases but only when you are dealing with constants. It is still WIP, some cases are changing, it is slightly abused for the print_type and other helper functions for development. I should write up some more documentation for it and its other kinds!!

(If there is no identifier passed to the decorator it just sets the constant identifier as the name of the function method it is under)