Implement WASI file functions and improve WASI structure

[kulcsaradam]

Introduce class WasiFunction to enable WASI to acces Instance resources. Implement WASI types and path_open and fd_close functions.

[kulcsaradam]

This pr tries to directly solve issue #133.

[kulcsaradam]

This patch introduces a new class WasiFunction which is only created for WASI functions. It is similar to ImportFunction, only differing in that it has a pointer to an instance instead of a void pointer. When an instance is created and a wasi functions is imported, this pointer will be set to the instance that imported it. Thus WASI functions could acces resources.

[kulcsaradam]

@clover2123 @ksh8281 With one of the latest patches, this pr will not build.

Looks like the std c++17 libraries that I used are missing in c++11 but are present (in the experimental library) in c++ 14. I would like to ask you for help on how to fix this, I could think of two options: 1, Make a wasi build option that uses std c++14 like with msvc 2, Use boost/filesystem library, the base of std::filesystem (the license is already present in the project)

I am open to any other suggestions too.

[clover2123]

To support various platforms, we lowered the default version of language and build option as to c++11. So we encourage to use c++11 version. If boost/filesystem library is compatible with c++11, please use it if there is no license issue.

[kulcsaradam]

Including Boost to work with Walrus proved to be highly difficult.

There are various problems, starting with that it is not recommended to build Boost with Cmake, instead it is prefered to build it's own engine, called b2. Different packages (as I have seen) cannot be built without the b2 system.

Other solutions I can think of instead of Boost are:

• Make Boost a dependency, like with CMake
• Raise required stdc++ to version 14 for wasi builds
• Build wabt with WASI ( there is an option, I am unsure if that is useable in practice)

Wabt wasi is highly experiemental and needs to be worked on.

Of course I am open to any other ideas.

[clover2123]

wabt engine currently uses uvwasi (https://github.com/nodejs/uvwasi) for its WASI implementation. Basically, uvwasi is implemented in C language, so I think that it's fine with our build system (CMake) How about considering uvwasi as an alternative of WASI implementation?

[kulcsaradam]

I think it is okay. I will see if I can implement it in Walrus and I will keep you updated on the process!

[kulcsaradam]

I have implemented uvwasi into Walrus.

Some tests were failling, especially on armv7 and aarch64, because uvwasi uses libuv, which is downloaded via git, so I added it to those builds (others did not fail because of this).

I will look into fixing the test problem on windows-x86-64 and update the patch once its done.

[clover2123]

What about including uvwasi as a submodule instead of copying the whole source files?

[kulcsaradam]

It is not an issue, I will be working on that then.

[kulcsaradam]

After addig uvwasi as a submodule I am having some build problems with macos and windows, which I am unsure how to fix yet, so I am open to any insight I can get.

[kulcsaradam]

Windows problems are fixed, it was a problem with msvc and templates. I will start fixing macos problems.

[kulcsaradam]

Macos problems were caused by cmake not fetching uvwasi's dependency libuv. All build problems should be fixed now.

[kulcsaradam]

I have rebased the patch to main branch and updated it with the suggested changes.