Starlark LSP

[keith]

There has been a lot of conversation over time about creating a starlark LSP bazel-contrib/vscode-bazel#1 I think this would be extremely helpful for rules authors to allow them to discover the many "magic" feeling attributes that are around depending on the context. Maybe this is something this group could own.

[alexeagle]

FWIW at BazelCon this year I discussed with a few Googlers who are on the team that would naturally own this. They haven't even considered working on it, and one told me that the Cider-only LSP that they do have may have been broken by the change to the Monaco editor. This is a hard thing to write, so I don't have any ideas for getting this project off the ground.

[alexeagle]

@cgrindel is thinking of picking this up now, see proposal: cgrindel/starlark-language-server#1

[withered-magic]

Came across this thread and wanted to share an implementation I ended up starting here! https://github.com/withered-magic/starpls

It's still in a rough WIP state, but it does support things like completions, hovers, auto-complete, and type inference/error diagnostics for most Starlark builtins and types. My goal is to fully implement the Starlark spec first, then begin adding Bazel-specific features, most likely starting with auto-complete for Bazel builtins.

[alexeagle]

I think this may be a dead end, since there's already a nice LSP over here https://github.com/facebook/buck2/tree/main/starlark-rust/starlark_lsp

the only downside is that it permits typed-starlark, which Bazel's Java starlark interpreter doesn't accept. @laurentlb might be interested in contributing at least the "ignore types" feature there, which would be a nice solution.

Oh, and I'm not sure how that LSP would be extensible so that it could support Bazel-specific globals. Perhaps the authors would be okay with just landing those, and enabling them when the extension is .bazel or something.

[laurentlb]

For the LSP, see also this discussion: facebook/starlark-rust#104 (comment). A new repository has just been created.

For ignoring type annotations, we can try to get agreement on the Starlark spec repository before trying to modify Blaze. There was also this related comment: google/starlark-go#439 (comment)

[withered-magic]

Ah I did see that one! I did an evaluation of it before working on my implementation, but I noticed that it was geared a bit more towards completion/goto-definitions for targets and labels, and didn't really have too much features around type inference/autocomplete for variables and methods, like

• Validating function arguments - the len invocation in x = len() should report a static error for the missing argument.
• Autocompleting fields - In the following snippet, with the cursor would be at the marked location, a developer might like for the capitalize() method to be autocompleted, knowing that greeting has type string:

greeting = 'Hello, world'
print(greeting.cap
               ^^^

I tried to make my implementation more focused on these sorts of use cases, as I do think features like this would greatly enhance the rule-writing experience, where common objects like ctx in rule definitions could have proper type information associated with them!

As for type annotations, while waiting for the official Starlark specification to be updated, perhaps using PEP 484-style type comments might be a good alternative? This was the approach I'm currently taking; since type information would be entirely held in comments, a third-party static analyzer wouldn't need to wait for the Starlark spec to support type annotations to be able to carry out type inference. For example, given this rule definition taken from the Bazel tutorial

def _foo_binary_impl(ctx # type: ctx
                    ):
    out = ctx.actions.declare_file(ctx.label.name)
    ctx.actions.write(
        output = out,
        content = "Hello\n",
    )

The type information provided by # type: ctx would allow autocomplete for ctx.actions.declare_file and ctx.actions.write.