Must haves

[jhpratt]

Use this discussion for suggestions of "must haves" for a custom linter. Please limit suggestions to one per top-level comment to allow for easier upvoting/downvoting and replies.

[jhpratt]

Lint implementations must be sandboxed.

[jhpratt]

Having it be in a single binary would require compiler integration, no?

I really have no need to write all of the machinery necessary for using wasm inside the compiler, especially given I'd have to write that in C++

Crates to compile and run wasm already exist, though? It's actually quite easy to use.

[chorman0773]

Having it be in a single binary would require compiler integration, no?

If you mean having it attached to the compiler by default, then yes, yes it would. Implementations could use the same machinery for proc-macros as for lints. If you have cargo, then cargo handles the details. If you don't... Well, dealing with proc-macros in rust-autotools are annoying, but I see no issues with lints fundamentally, it's just another proc-macro.mk.in.

Crates to compile and run wasm already exist, though? It's actually quite easy to use.

Sure, in rust. lccc, my implementation, is written in C++, and does not have a hard dependency on any host rust compiler (so that it can be bootstrapped), so if this was integrated into the base compiler, then I'd have to write the lint support directly into the compiler, which means that I'd have to write the wasm interpreter.

[jhpratt]

At least personally, I don't see the need to integrate this into the compiler, even long term. That was discussed in another comment chain, so I won't repeat it here. So long as it's standalone, alternative compiler implementations wouldn't need an interpreter.

[jhpratt]

Would this be acceptable to be placed under "could have"? I'm convinced this isn't necessary for the MVP, but I still think this is a good idea in the long term.

[jhpratt]

^^ Bueller?