Enable module-wide symbol indexing and operations

[daviwil]

We need to have a more robust and reliable method for indexing symbols across a module or modules within a workspace so that the following operations work as expected:

• Go to definition
• Find all references
• Rename symbol

[TylerLeonhardt]

Did you make any progress on this one?

[daviwil]

Nope, never had time. One thing I wanted to do was to create a "Project" subsystem for PSES which is able to index files in a way that will be semantically correct for the language and really efficient. It is a nontrivial amount of work. Maybe @SeeminglyScience might want to look into it someday ;)

[SeeminglyScience]

Coincidentally I've thought about this a lot over the last month or so. I think an ideal implementation would be being able to select a target psd1 file the same way the C# extension can select a target csproj.

Unfortunately even with that system, this is way more complex than it may seem on the surface. Ideally, this would work purely from static analysis. Realistically, we'd either have to enforce a standard way of loading functions from separate files or load the module and operate based on the state. And I have a hard time seeing the former as a real possibility.

Actually executing the module is the only way I see this working reliably but I think there are a lot of non-technical challenges with that. You'd have to communicate clearly that the simple act of opening a workspace might execute code, and it'd definitely have to be opt-in only.

I think workspace profiles are a really good first step into that space, and I wouldn't put too much time into thinking about this feature until that's implemented.

[rkeithhill]

I dunno about relying upon module infrastructure. I know a few teams where I work that have a big hairball of scripts they dot source and don't use modules at all.

Couldn't we add a setting (or psproj.json file) where the user could have control over where we look for script files? Could even default to the entire repo with some preset excludes (**/node_modules, **/.git, etc). That doesn't address the "semantically correct" part which I believe means following the trail of dot-sourcing. But it would still be pretty darn nice.

[SeeminglyScience]

@rkeithhill Yeah that makes sense. We could have it act more like the references code lens currently does but with a way to exclude (well, the references code lens would need to follow that exclusion as well obviously)

I wonder if the exclude setting should be part of a new static project file, or setting set in the workspace profile via a command like Set-EditorOption. If we go with the former it may be worth opening a discussion with the folks behind the non-PSES PowerShell focused editors.

That doesn't address the "semantically correct" part which I believe means following the trail of dot-sourcing. But it would still be pretty darn nice.

Yeah, I recently stripped out the AST inference code from PS Core and replaced all the private API calls with (slower) public ones as part of a revamp of my editor command module. Included in that logic is safe expression evaluation. If all goes well that would be very useful for implementing that (also for implementing find references for classes)

Edit: I definitely still think module specific logic should be implemented as well, especially to be able to handle things like private functions differently. But searching the whole workspace with an exclusion list should absolutely be implemented at least as a fall back.