I might be interested in tackling this starterBug. If the first step is exposing the functionality from indexstore-db, I could use some guidance on how to test the functionality. There are only a few unit tests and they do not create a DB or an indexStoreLibrary. Is there an easy way to do this
Whether its with a unit test or not, I am mostly just looking for a way to easily see the result of a function in IndexStoreDB.
There is no infrastructure to test the DB right now. This is something I'm keenly aware of and want to improve soon, but it's probably beyond the scope of a starter bug. I'm okay with exposing these existing functions without adding tests.
Whether its with a unit test or not, I am mostly just looking for a way to easily see the result of a function in IndexStoreDB .
For now the easiest way may be to log them from inside sourcekit-lsp.
Based on that, I started working on the lsp project first. I created a symbolsRequest TextDocumentRequest struct and added the necessary plumbing so that the following code works in a test:
However, I'm still not sure how I would test the result of something that uses indexDB. None of the unit tests seem to use index even in the lsp project, and when running the project for real, I don't know how to see the logs.
In VSCode, I'm seeing logs such as
[Trace - 7:41:51 AM] Received notification 'textDocument/publishDiagnostics'.
But I suspect that that's coming from the VSCode extension (Typescript) rather than the Swift server.
Also, if it seems like I am on the wrong track and the issue would be best left for someone else, please let me know! I don't want to waste your time if I'm unlikely to be successful
Yes, that is exactly what I needed! Thank you so much!
It seems like the environment variable is different than the logging setting that you can set in VSCode settings even though the logs end up in the same place. Not what I expected, but I'll take it!
It's also seems to only work with log and not print.
The setting is mostly about tracing the requests and/or responses, not about informational logging from inside the service. I'd like to do some more work on how we categorize logs to be more useful, and then we could expose it in a more useful way from the settings.
The way that we communicate with the editor is to send jsonrpc packets over stdout/stdin. Printing to stdout will interfere with that, so don't do that If you print to stderr the editor may or may not capture that - in vscode I think it would work.