Crate ezno_checker

Expand description

§Ezno’s Checker

Contains type checking logic for TypeScript and logic for running type checking checks over ezno-parser.

See specification for all currently implemented checking features.

§Definitions

At the moment it comes packaged with internal.ts.d.bin. This can either be a syntactic or binary definition of methods, types and such in the runtime.

§Adding type checking outside of the Ezno toolchain

While the checker is indented for the Ezno toolchain and its parser, most (3/4) of the checker code is AST agnostic. The synthesis directory that contains the bindings with ezno-parser can disabled with no-default-features. You can build your own AST <-> Type checking APIs using it for adding Ezno’s type checking features into other toolchains (without needing to parse or convert ASTs).

#TODO ASTImplementation, synthesis folder rule

§Documentation

A sparse documentation of some to the internals of the functions, structures and processes exists in the /documentation folder.

§Testing

Set EZNO_DEBUG to any value to trace diagnostic information from the crate::utils::notify! macro (In powershell = $Env:EZNO_DEBUG=1)

Re-exports§

pub use context::Environment;
pub use context::GeneralContext;
pub use context::RootContext;
pub use context::Scope;
pub use context::VariableRegisterArguments;
pub use diagnostics::Diagnostic;
pub use diagnostics::DiagnosticKind;
pub use diagnostics::DiagnosticsContainer;
pub use types::calling::call_type_handle_errors;
pub use types::generics::GenericTypeParameters;
pub use types::properties::PropertyValue;
pub use types::subtyping;
pub use types::Constant;
pub use types::Type;
pub use types::TypeId;
pub use types::TypeStore;
pub use source_map;

Modules§

context: Environments provide maps between string keys and types and variables
diagnostics: Contains type checking errors, warnings and related structures
events: Side effects which are not described in return types… Such as variable reassignment, function calling etc
features: Contains implementations of specific JavaScript items and how Ezno handles them. Contains
synthesis: Synthesis is the aim of giving types to AST structures Synthesis and checking are split between two passes The aim is a AST cannot known to be valid until it everything has been attempted to be given a type Unknown types are [types::Meta]
types
utilities: These should probably be made into reusable crates at some point

Structs§

CheckOutput: Used for transformers and other things after checking!!!!
CheckingData: Contains logic for checking phase (none of the later steps) All data is global, non local to current scope TODO some of these should be mutex / ref cell
Chronometer
FunctionId: TODO split for annotations based functions
ModuleData: Contains all the modules and mappings for import statements
SourceId: A identifier for a crate::Source
TypeCheckOptions: Options for type checking TODO figure out compat with tsc
TypeMappings: PER MODULE TypeMappings is used to retaining information between passes, including the synthesise and checking passes This for use in the both use in the compiler and compiler plugins Checking things are held on [crate::Memory], function things are held on [crate::HoistedFunctionContainer] and module things on crate::ModuleData
VariableId
VariablesToTypes