[proposal] code analysis

[ZacLN]

As a next step in terms of features I was thinking of integrating some static code analysis type features. First thoughts as to what it would do:

• Parse the file you are working.

• Know what types/functions etc. are being defined thus providing hover, completion and signature help for them. Also for obvious cases we could learn the type of variables (e.g. those bound to the result of a constructor).

• Parse inside each of these top level blocks providing the same things at the local level only (e.g. for a function we'd know the type of the argument if specified).

Key to all of this is retaining the relation between the AST representation and the layout of the text which precludes an easy solution. I think we could either start ground up or attempt to fork Lint.jl (which does all the scope tracking) adding the AST->document range relation. The latter would also have the benefit of not repeating the work the linter does twice.

Thoughts?

[ZacLN]

a simple implementation

[davidanthoff]

Yeah, I think this is definitely the right approach. I guess one question is whether these kinds of static analysis passes should be triggered per file, or whether the language server should parse the whole project folder and then cache things...

Also, see this. I'm not sure what the best way forward is on this. It would clearly be best if JuliaParser could somehow be utilized in all of this, but I think right now it simply doesn't spit out all the information that would be needed for a fully functional static analysis/editor plugin. I do think that the whole Roslyn architecture is a really good guide, but it is a lot of work.

So I think I'm in favor of anything that makes progress right now, whether it is the "big" solution, or some more hacky things.

[ZacLN]

Ok I've made progress following the hacky route... I delved into JuliaParser and your proposal there but found it a little too difficult to work with without getting to understand it in depth.

Combined with the partial document syncing I've got a mess of code that:

• reads blocks from local files, tracks their location (and ~keeps AST line info correct)
• re-parses only changed code blocks
• manages to skip over broken blocks (i.e. failure to close functions)
• tracks global variables added to the namespace
• tracks some local variables/types in blocks
• will update linter diagnostics only on changed blocks (currently commented out)

At the moment it simply spits out diagnostics on hover for what the block contains but it's pretty rudimentary to generate for each file:

• a store of global vars allowing hovers/completions/signature help
• a graph listing where functions defined in the curent document are called from
• block specific hovers/completions/signature help for local vars given there is enough type information (i.e. relies on writing fairly explicit typed code)

I've not been able to work out how to send information on what the current project is to the server, any ideas?

[ZacLN]

Thinking about how the TypeScript project scope system works it must just add documents that are referenced by the current open ones (i.e. in Julia search blocks for those calling include) but this would only make #29 worse

[davidanthoff]

I've not been able to work out how to send information on what the current project is to the server, any ideas?

I think the initialize request sends the rootPath, that would probably be the info to use?

Same for the linter problem, I think we could just limit linting to files that are children of rootPath?

I'm not clear right now what happens if one opens a new folder. Is the language server restarted? Or would we get a shutdown request, and then another initialize?

[ZacLN]

Great, I've added this to the LanguageServer.

On the opening a new folder a new instance of vscode is started I think.

[davidanthoff]

@ZacLN I'll close this, you essentially did this for v0.6.0, right?

[ZacLN]

Yep this is the CSTParser stuff