search

julia-vscode / StaticLint.jl

Static Code Analysis for Julia
Other
145 stars 28 forks source link

Match files to correct environment #9

Open davidanthoff opened 6 years ago

davidanthoff commented 6 years ago

~I think we really need to get rid of things like the global store variable and _Module etc. Maybe the best solution would be to have a type called StaticLintSession that has fields for all of these, and then a client has to pass an instance of that to any function it calls in StaticLint?~

I think we'll have to support a scenario one LS process will handle different folders that are open at the same time, but that have different name resolution because they have different Project.toml files. A Project.toml can actually redefine how a given name resolves to a given package, and so we need the ability to have different stores, where the same name actually brings back symbols from different packages... I think something like StaticLintSession might be the easiest for that.

EricForgy commented 4 years ago

Is the related to an issue I am seeing?

I am working on package Foo and Foo has a dependency of an external package Bar, but I have Bar deved in Foo's environment. If I make a change to a method signature for a method in Bar, I can't seem to get linting to work with the new method signature. I've tried reindexing and I've tried reloading VS Code.

The only thing that seems to work is to tag a new version of Bar. This makes me think that StaticLint is not using the new signatures from the deved Bar.

Is that right?

davidanthoff commented 4 years ago

No, different issue. We'll rework how all of this is handled post Juliacon.