Open xFrednet opened 2 years ago
This was previously discussed in an extremely long issue last year. I believe consensus was to start with dylibs and keep wasm open as a possibility. This was scaled back from my original goal of always using wasm. Consensus also existed for keeping the door open to sandboxing, even if it didn't originally exist. This would simply be done by a notice that non-sandboxed behavior (like a network call) isn't guaranteed.
Somewhere in that issue I likely referenced wasm_plugin_host
and wasm_plugin_guest
, which should make things a bit easier. The serialization and federalization is a valid point, but I don't think the speed difference will be too noticeable — if something takes 200ms instead of 100ms, it's still sufficiently fast to the extent we shouldn't care. Wasm is also advancing quite a bit, so capabilities aren't fixed by any means.
I had the feeling that there was no real consensus, but I might be mistaken. Using dynamic libs is fine for me. That means less work for me, but might limit us in the future. In that case, we can keep this open as a general discussion place in case someone has a related idea or suggestion.
As a side note, I believe the difference would be more than 2x not having pointers means that every access has to go over an id -> node
map which would slow down every access. Alternatively, we could optimize the layout for this, like THIR does AFAIK. But as you say, we can for now advance with dynamic loading.
In https://github.com/rust-marker/marker/issues/177 it was suggested to maybe not have lint crates, but #[test]
like functions:
Regarding the static linking approach I think it's just a simpler way for people to use that. This is basically reminiscent of the approach that rust's test and benchmark frameworks use. The proc macro
#[test]
or#[bench]
that collects the code that you want to run, and then a test/benchmarking harness they you need to manually invoke in yourmain()
that provides you with the CLI over the "tests/benches" you wrote.
The comment also includes some ideas how this could be implemented
I think this is something worth considering before v1.0.0
Hey :wave: I'm currently investigating ways, to load one or several lint crates from the lint driver. The current prototype loads lint crates as dynamic libraries and simply passes rust types to them. This is problematic, since Rust doesn't have a stable ABI. In fact, reading more about it, I'm surprised that it has worked flawlessly this far. I want to find a stable way to load them, as that might affect, how data is modeled and represented.
This also plays into this suggestion/discussion that lints should ideally be sandboxed.
This detailed blog about Plugins in Rust lists a few ways how this can be accomplished:
Currently, there appears to be no ideal way to add plugin support to rust projects. Every solution I found can be derived from the first four listed ideas. I like the idea of using WASM and sandboxing everything by default, like dtolnay/watt does for proc macros. However, this collides with a tree representation with several references.
Dynamic libraries seam to be ideal, with the exception that they can't be sandboxed and restrict the implementation to a stable ABI (Meaning no dyn pointers)
cc: https://github.com/rust-linting/rust-linting/issues/8