Static type checking

[andycraig]

trafficstars

@kcf-jackson has created the {typeChecker} package, an experimental static type checker for R. I had a try at integrating it into {languageserver}, in the types branch of my fork. It calls {typeChecker} alongside {lintr}, and returns the results of both as diagnostics.

Here it is in action with VS Code. The type checking problems are underlined, and the problem details are shown in the terminal.

Installation:

# install.packages("remotes")
remotes::install_github("kcf-jackson/typeChecker")
remotes::install_github("andycraig/languageserver@types")

It currently works on single files only, so it won't type check functions declared in one file but used in another.

Since type annotations are experimental for R I'm not sure we'd want to merge my types branch into master at this stage. But it's there for anyone who wants to try it out. My plan is to periodically rebase it onto the master branch to keep it up to date.

[randy3k]

It is interesting. We could definitely keep an eye on it. I would be happy to merge it into master if we make it optional and clearly state that it is experimental.

[andycraig]

@randy3k It's effectively optional at the moment because if {typeChecker} isn't installed it fails gracefully and just returns the {lintr} diagnostics as normal. So I think I would just need to add something to the README to note that the feature is available but experimental.

@kcf-jackson Happy for {typeChecker} support to be merged into {languageserver}'s master branch? Only downside (?) I can think of is that you might get more support request issues raised at the {typeChecker} repo.

[randy3k]

I think we should have an option to turn it off even the package is installed. Perhaps an option like languageserver.diagnostics_type_check = FALSE. And users need to opt in specifically.

[andycraig]

@randy3k Yes, that's a good idea.

[kcf-jackson]

@andycraig Happy to merge. Given that the package is experimental, I see issues as upside as they help improve the package.

Fully agree with @randy3k to keep the feature optional and experimental. This also makes it easier to switch in case R core releases an official version or others come up with a better implementation.

[renkun-ken]

I agree. I don't see an obvious downside of this if we mark it experimental.

[andycraig]

Great! I will put together a PR.