Should haves

[jhpratt]

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

[DevinR528]

Crate-specific lints should be able to be bundled with the library they are for and read/registered by the driver.

[jhpratt]

I've thought about this. Bundling with the library seems infeasible unless we auto-detect direct dependencies. Even then, we'd have to validate that the lint author can publish that crate on crates.io (which requires the full crate registry) and restrict publishing to those people.

[DevinR528]

Is this way to hacky?

// inside a crate with exports that should be linted
#[cfg(feature = "linter_plugin")] // the driver would need to be able to turn this on
#[no_mangle]
pub static PLUGIN_BYTES: &[u8] = include_bytes!("plugin.wasm"); // a wasm compiled lint

then load the dylib using libloading (yeah this is getting wonky) and get the bytes and load the wasm.

[jhpratt]

Something about that approach just feels wrong. I think having a separate registry, even if just at first, makes more sense. I presume some company would be willing to sponsor the hosting, but that's speculation of course. An advantage there is that the registry could optimize the wasm upon upload.

[jhpratt]

I think this would be best as a possible long-term goal that would go alongside rustc/cargo/crates.io integration, if that ultimately happens.

[jhpratt]

As an addendum, having a default "all" group for each crate would be convenient.

[xFrednet]

Support features for lints like they already work for dependencies:

• This means supporting optional lints, similar to how the optional = 1 flag works for dependencies
• Lint code should support conditional compilation and optional dependencies

[flip1995]

Definitely +1 for this. Crates with different feature sets might want to ship different lints (or lint levels) depending on which features are enabled.

I share the concern regarding this effectively limiting us from distributing precompiled lints, as was mentioned.

This is still a bad idea IMO (see #6 (comment)). It just restricts us from adding nice features like the requested in the OP. There's a reason why cargo downloads and compiles source code and why crates.io doesn't store pre-compiled binaries.

[jhpratt]

Yeah, the outcome of this realistically depends on #6 as a whole.

[jhpratt]

I'm not sure this is something we should explicitly guarantee given the future possibility of pre-shipped dylibs that are sandboxed, which would necessarily preclude conditional compilation. Optional lint packages would go alongside whatever registry ends up being used.

[xFrednet]

Would it be okay for everyone to add this as an unstable feature for now?

I still believe that this would be very useful, and it should be quite easy to allow for with the currently planned discovery option for the start. Not allowing it would probably be more work. Therefore, I think a good solution would be to allow the usage of features for now but also document that this is unstable and might change in the future.

[jhpratt]

I mean I don't think our current plan for starting out would necessarily restrict using cargo features, but it's not something I'd particularly like to encourage for the reasons stated. So as long as it's documented that the behavior isn't guaranteed for the future (similar to what I've documented for file system access, for example), that seems reasonable.

[jhpratt]

I just realized this was never explicitly stated anywhere: the linter should be able to work with IDEs. This likely means being able to output machine-readable JSON.

[xFrednet]

+1 I would make a stronger statement that we should use the diagnostic emission from rustc. That will automatically provide us with console & JSON output for diagnostics and ensures that the output structure is always the same (within the rust eco system).

[jhpratt]

I'd consider that an implementation detail, personally. Not that we shouldn't do it.