Allow using statements to point to live package code

[ZacLN]

Partner of https://github.com/julia-vscode/StaticLint.jl/pull/103

The key question at this point is what files we will allow/determine to be packages. One approach would be to limit it to workspace folders that have the correct structure (i.e. a folder X with src/X.jl within it)

[codecov[bot]]

Codecov Report

Merging #562 into master will decrease coverage by 0.04%. The diff coverage is 25%.

@@            Coverage Diff             @@
##           master     #562      +/-   ##
==========================================
- Coverage   28.46%   28.42%   -0.05%     
==========================================
  Files          23       23              
  Lines        1686     1706      +20     
==========================================
+ Hits          480      485       +5     
- Misses       1206     1221      +15

Impacted Files	Coverage Δ
src/requests/completions.jl	0% <0%> (ø)	:arrow_up:
src/languageserverinstance.jl	41.46% <35.71%> (-1.19%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update d8faa95...569b653. Read the comment docs.

[ZacLN]

https://github.com/julia-vscode/julia-vscode/issues/1023

[davidanthoff]

Hm, it seems to me that we generally need to resolve this via the active environment, right? Whereas this just seems to be based on file system structure?

So I think if we see a using statement (that is not a relative path type thingy), then we look into the active env. If the package is deved and the path to the deved package is in our workspace, then we use the live CSTParser tree to resolve symbols, otherwise we use what we get from SymbolServer, right?

[ZacLN]

This is just the internal handling of this (not the env handling part we discuss the other day) and in particular looks to make available the 'main' package when editing it is being edited - this is not information explicitly held in the Project.toml. I've tightened up the code that decides whether to add a 'live' package to reflect this.

[davidanthoff]

I think I still don't fully understand this :)

Lets say someone opens the root folder for package Foo.

Inside the src folder we would never expect a using Foo statement, right? Only include statements to assemble everything together. So I assume that this here is not needed when a user edits the files in src, right?

For files outside of src, it seems to me that we should always and only go through an environment to resolve using X statements. Right now the UI is such that if I open the folder for package Foo, and my active env does not have Foo deved, I get a warning that I should open an env that contains Foo. So the model we have right now is that if someone opens a package folder, then they should have an env active where that package is deved, and then resolving using Foo from folders outside of src should go via the enviornment, right?

I think right now I just don't understand the scenario where we should try to resolve this purely pased on file location.

[ZacLN]

inside the src folder we would never expect a using Foo statement, right?

Unfortunately we do, this seems silly.

Keeping with your example above, if I'm editing Foo I think I want all references to Foo within that context (i.e. the package directory) to point to what I'm editing, not a cached version. If, for example, I'm writing tests I'd like to be able to refer to functions/features I've just added.

[ZacLN]

Continuing this - isn't this what we discussed, the cache should only be used for code that is outside the current workspace?

[ZacLN]

bump @julia-vscode/core I think this could do with some discussion

[davidanthoff]

@ZacLN I'd say we can try to get that in soon after Juliacon? Is the next step that you resolve merge conflicts, and then we review properly?

[davidanthoff]

And now we need to get tests to pass :)