Add command to open AST node type declaration in AST Viewer

[aeisenberg]

When a user selects an AST Node in the AST Viewer, there should be a way to open the underlying QL type declaration.

To simplify things, we will assume that all AST Nodes that correspond to types have the type name in labels. Eg- [Namespace] MyNamespace.

[aeisenberg]

Here is my plan:

1. Take advantage of the running language server to request a type definition using the vscode.executeTypeDefinitionProvider.
2. This command requires a file URI and a location in that URI, so generate a simple ql file in a temp folder with an import statement and a reference to the type we are trying to open.
3. Also, need to create a qlpack.yml file with the name of the language library in it.

Unfortunately, this is not working at the moment. It looks like the language server is not recognizing this file since it is not in the scope of its workspace. I may need to restart the language server with knowledge of this synthetic folder. Not sure the best way to do this. I will need to ask around.

[adityasharad]

Check out what we do for quick query: that involves creating a new query in a synthetic query pack in the workspace suitable for the current DB's language, and you might be able to reuse that mechanism.

[aeisenberg]

Unfortunately, that won't work in this case. It was the direction I originally tried. The difference is that the quick query mechanism explicitly adds an extra folder to the workspace and restarts the cli with this extra folder.

I thought about adding it to the quick query folder (and deleting when it's done), but that would be visible to the user and would possibly change the qlpack to a different language.

[aeisenberg]

I did a look at the IDE Server code. It looks like we can only update the IDE Server workspace to add more folders by restarting the language server. It also looks like the IDE Server only adds folders from the vscode workspace into the language workspace.

We don't want to add the synthetic qlpack to a folder that's in the vscode workspace since this will be visible to users.

I think what we want is to add the ability to start the language server with an extra folder that is not visible to the user (ie- it's outside of the vscode workspace and possibly a temp folder that can get cleaned up). We can use this as a scratch folder for adding things like this. Though, we don't want synthetic modules in this folder to become accidentally imported.

[alexet]

I think it would be better to just add a new method to the ideserver that searches for a type by name across a given set of qlpacks. We probably want a special implementation that doesn't bother actually binding the code and only parses it so that it will run in a reasonable amount of time.

I also think we should think about what it is that users want. Why do users want to jump to the class itself? Do they want to know the exact implementation details. Or do they actually want the documentation? I would expect it to be the latter. To get useful things (like the list of things you can call on the class) would require a bunch of clicking around and/or filtering the private methods manually (some class have a lot of implementation detail). However even if it is the case this is probably a reasonable approximation.

Finally we should think about whether there is a way to get the exact class location from the query. As currently written we can't get the location of the class on disk in QL and it would need special handling. Even if we did add such a feature we probably would want to be careful to avoid breaking the cache and it would probably be a lot of work. So I don't think it is worth it.

[aeisenberg]

Maybe linking to documentation to see all publicly available members would be sufficient. Though, I'm trying to avoid forcing the users to leave vscode to see this. Since it seems like implementing this feature as I imagined is more complex than I originally thought, I'll have a rethink about what to do.

[aeisenberg]

Just tried an experiment where we create a virtual file and use that for navigation. This means creating a text document but not saving it. Unfortunately, this means that the text document is opened in an unsaved text editor, visible to the user.

This is not an approach we can take.

[aeisenberg]

Moved this issue out of in progress since I can't implement the proper approach at the moment.