Integrate linting

[shs96c]

This builds on top of #528 in order to integrate lint tests. The second commit ("Automatically generate lint tests...") has more information in how to use the generated lint tests, and integrates the feature into the "anvil" demo.

[Kernald]

Note that this breaks the generated documentation - Stardoc doesn't follow the macro indirection.

[shs96c]

That's suboptimal. I'll fix that now.

[shs96c]

I've fixed the problem with docs generation, but I've had to work around an issue in stardoc.

[alexeagle]

That workaround is the same thing we do in rules_nodejs. Expose the rule to stardoc and the macro to users

[jeffzoch]

So does this remove the need to manually define kt_lint tests? They get autogenerated now ?

[Bencodes]

This seems like something that should be opt-in so that kt-lint targets aren't being put on the golden path of repositories that don't rely on it.

[Kernald]

Note that as I commented on https://github.com/bazelbuild/rules_kotlin/commit/83224e46eee88b208e89b0e329f96e5b33b3f66c#r49787303 (which I don't think anyone noticed as I commented on the commit after it was merged), the logic currently used to implement ktlint_fix breaks with ktlint > 0.40 (https://github.com/pinterest/ktlint/issues/1131). It's probably worth figuring out a solution to this before going forward with this PR as well, as ktlint 0.41, including this change, has been released over a month ago.

[gibfahn]

So does this remove the need to manually define kt_lint tests? They get autogenerated now ?

Yes, if you opt in they get autogenerated.

This seems like something that should be opt-in so that kt-lint targets aren't being put on the golden path of repositories that don't rely on it.

Docs in the PR say "This functionality is opt-in", is there a way we could make this more clear?

[shs96c]

I see that @gibfahn has beaten me to answering the two most pressing questions.

Since the version of ktlint is pinned in this repo, I think it'd be okay to update it separately to this, but if people feel it's a blocker, I can explore the work that needs to be done and create a separate PR for that, since the ktlint_fix rule has already landed in this repo.

[Kernald]

Since the version of ktlint is pinned in this repo, I think it'd be okay to update it separately to this, but if people feel it's a blocker, I can explore the work that needs to be done and create a separate PR for that, since the ktlint_fix rule has already landed in this repo.

Maybe opening an issue to track this and adding some documentation about this being a known issue and a link to it would be a good compromise?

[shs96c]

That's a great idea. I'm completely onboard with making ktlint_fix work with the recent ktlint release :) Filed #535 to track it, and I intend to work on it this week.