This section of the code loops infinitely with input `.

#[test]
fn test() {
    let mut fs = fe::FileSet::new();
    let o = &mut fe::objects::Objects::new();
    let el = &mut fe::errors::ErrorList::new();
    parse_file(o, &mut fs, el, "/a", "`", false);
}

Sample:

package main

func broken(elems ...int) {}

func main() {
  broken()
}

thread 'test_std_temp' panicked at 'index out of bounds: the len is 0 but the index is 0', codegen/src/codegen.rs:965:32

This is a pretty amazing project, thanks for putting it out there :)

The Dot import syntax brings the entire package into the current namespace. So, you don’t have to call the functions using the package name. You can directly call them.

Reproduction code

package main

import (
  . "fmt2"
)

func main() {
  Println("Hello, World!")
}

Expected Results

That it would print out "Hello, World!"

Actual Results

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', ...goscript/codegen/src/package.rs:47:60

Hello! Wonderful project. I was playing around with embedded structs as they're a golang feature I quite like, and I found that fields and methods aren't promoted in goscript like they are in golang proper:

package main

import (
	"fmt"
)

type Base struct {
	name string
}
func (b Base) PrintField() {
	fmt.Println(b.name)
}

type Container struct {
	Base
}

func main() {
	t := Container{Base{"go"}}
        //t.PrintField() //error in goscript, but works in golang
	t.Base.PrintField() //have to use this instead
}

I'm not sure if this is an issue with the go specs, or simply this implementation. I'm not even sure if implementing field promotion is on the table. But I felt it was worth bringing up anyway. The error specifically when trying to run this script is: thread 'main' panicked at 'no entry found for key', ...\vm\src\metadata.rs:493:9 so it seems to be an error with field name resolution.

the only change of functionality is in the function shorten_with_ellipsis. I also hope I fixed the issue with array into_iter()... (I didn't test it, there may be some errors in it...)

This PR aims to fix two problems with octal integers:

1. It fixes the radix notation for integer conversion.
2. It adds support for "bare" octal notation, e.g. 01, 023 etc. Currently those numbers are treated as if they were decimals (1, 23), whilst their decimal value is different (1, 27).

Also now integers such as 09 etc. throw lexer error, instead of being converted to decimals, as they should.

smol brings in a lot of IO related dependencies that are not used by goscript. They are also quite problematic when compiling to WebAssembly. Fortunately since they are not used, we can just remove them and also get faster compile times and a smaller dependency tree out of it.

I found that running a fuzz test on the parser uncovers some bugs. After installing cargo-fuzz, the target can be run with cargo +nightly fuzz run parse_file.

After building for the wasm32-wasi target, running the engine failed and I narrowed it down to calls to canonicalize() and printing the errors give the following message:

Error { kind: Unsupported, message: "operation not supported on this platform" }

It appears that wasi doesn't support canonicalize.

The changes I made simply skip invoking canonicalize() if the build target is wasm-wasi, and I don't think it's too much to just require that wasm users of the library provide an absolute path if they wish to run goscripts.