vscode-powershell
vscode-powershell copied to clipboard
PowerShell
Implement document and workspace symbol providers for classes
This requires an implementation of the DocumentSymbolProvider and WorkspaceSymbolProvider interfaces. Relevant code will need to be added to PowerShell Editor Services to support this behavior.
Assigning Keith since this is for the feature he was interested in helping with. I'll provide more details privately.
Yep, that's something we haven't finished yet. Seems like you had commented on the Editor Services issue for this a while back:
https://github.com/PowerShell/PowerShellEditorServices/issues/14
Sorry about that :/ I'll see if I can get some help to get that implemented for the 0.8.0 release!
Any updates on this? I have version 0.9.0 now and this doesn't seem to work.
Any updates?
This is a big missing piece for me. I try to do most of the development as classes, and wrap them with functions to get the task based abstractions. But that means navigation is only available for a minor subset of my code.
Just for the record, @mmajcica, enums being not colored is an EditorSyntax issue. That's all the syntax highlighting. This issue is opened there: https://github.com/PowerShell/EditorSyntax/issues/29
Thank you all for your patience! Classes and enums are lacking at the moment for sure. The best thing to do is 👍 issues as that is one factor we look at for priority.
Go to definition for class and class methods do not work on ps core
That's a 2.0.0 feature. Compatibility with PowerShell v3/v4 mean we can't use new APIs that expose class ASTs. So no class symbols until we drop v3/v4 support.
@rjmholt, that doesn't sound correct. That doesn't sound like a smart thing to do, to not be able to use a new API because you must still support an old API. At that rate, we'd never have moved past DOS. If this is such a problem, maybe both versions of the extension should be made available, but I would like to think that should not be needed.
Agreed, it would be much better to provide both versions. Right now we're managing with some difficult with relatively small code base, but can't imagine how complex it will be as our code base gets larger.
@rjmholt Should I expect go to definition to work now if I'm using the 2.0 preview extension? Just installed and it doesn't appear to be working.
Not yet. First step is dropping support for v3 AST which 2.0 preview does. Next step is to add support for classes (and enums).
Agreed, it would be much better to provide both versions. Right now we're managing with some difficult with relatively small code base, but can't imagine how complex it will be as our code base gets larger.
Precisely the problem we face in this code base. We've been trying to make the code more maintainable since we're spread thin across 30k lines of C#, and tangling things up in compile-time macros means the code gets harder to reason about and we have to juggle multiple DLLs to load at runtime.
The decision to not compile a different DLL for PS v3/4 (compared to PS v5) was made by @daviwil in an earlier iteration of the project, but adding the capability back in presented a significant architecture-changing work item for new maintainers.
Anyway, now that PSReadLine means we are incompatible with PS v3/4, we can feasibly move back to an AstVisitor2 implementation without much complexity. But there are other things that need fixing first. It's the kind of thing that a community contribution would probably add much faster.
This will be trickier than anticipated. Uncommenting the code that already existed didn't really do much. Here's what it has:
- Class method symbols (but not references)
- Class constructor symbols (but not references)
Here's what it's missing:
- Class property symbols and references
- Class (as in the type itself) symbols and references
- Class method references
- Class constructor references
- Enum symbols and references
References here means actually going through and figuring out that a symbol ([MyClass]::Foo) is a reference of a class symbol (in this case a property of class MyClass). This will be tricky with non-static members... and will probably be best effort.
So yeah. Lot's to do.
@lesterm5150 it's definitely noted as needed but the current highest priority is getting the extension stabilized with the new revamped internal engine to the point it's good for a stable release.
Not sure if this been reported, but when editing a script that contains classes, the breadcrumb at the top of the script does not work for any class/method/enum. Since I use classes, this is very frustrating :(
as an heavy user of classes in all bigger projects, the ETA (or knowing any alternative approach) would be nice
Fixed by https://github.com/PowerShell/PowerShellEditorServices/pull/1984
@andschwa working great! I have about as complex of a class as it gets in ModuleFast, and methods aren't showing up for some reason for the most part, I think maybe because I implement IComparable and it's only picking up those base methods like Equals?
https://github.com/JustinGrote/ModuleFast/blob/b531aa9ee95eb5941a064c9c0d0f2892e298db15/ModuleFast.psm1#L608-L620
I have less complex classes that work fine and show all methods like NuGetRange
Let me know if this needs a new issue.
@JustinGrote I know it's confusing, but those three screenshots all look like completions which are handled via the PowerShell completion engine, so perhaps an issue there? After you've typed out the method name (with at least () so the PowerShell parser knows it's a method invocation) can you do "go-to definition" on it? And if you pull up the Outline view, do you see all your methods?
Yeah there's typically nothing we can do in the extension to make new completions appear.
That said, you might be hitting PowerShell/PowerShellEditorServices#1810 which is our problem. If it shows up after a Esc then Ctrl + Space then it's ours. If not, then you'd want to open in PowerShell/PowerShell
@andschwa @SeeminglyScience oops I conflated two different things, you're right! Sorry about that, doing a quick symbol search and I'm seeing what I expect to see as well. Thanks!