John-John Tedro

We currently only support matching over external structs, such as: ```rust #[derive(Any)] struct External { #[rune(get)] field: u32, } ``` Which would allow for the following in Rune: ```rust pub...

Lossless parsing would be a big boon for having better LSP support which can tolerate partial code much better.

This introduces a basic C API which allows for setting up and running Rune in C. There's still a bunch of important things missing: * Full interaction with the stack....

A nested import where the item imported is the same as the module being imported causes import resolution to spin forever. For example, like this: ```rust mod foo {} use...

While working on cleanup for `VmExecution` it became apparent to me that it should be possible to re-use the same virtual machine in `VmExecution`. `VmExecution` currently is essentially a stack...

So we almost have all the support we need for benchmarks with the `#[bench]` attribute in order to replace all benchmarks that are currently written in Rust. What's missing is...

Runtime traits to represent protocols

2

We currently have "protocols" to implement various functions. These are really just free instance functions with custom name hashes that can't be named dynamically. This means that protocol impls currently...

Use dynamically dispatched generics to reduce namespace contamination

1

Come up with a generics scheme that works at runtime and allows for: * Dynamically dispatching a function call to the correct implementation depending on the type of the arguments....

Macros in statement positions might produce expressions *or* statements. This causes issues if the macro produces an item, because items need to be indexed *before* macros using them in case...

This will be required for native items (functions, types, macros, ...) to be known by the language server so that they can compile without having to load the native modules...