-
Notifications
You must be signed in to change notification settings - Fork 8
Integrate StaticLint and SymbolServer #61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
git-subtree-dir: packages/JSONRPC git-subtree-split: 9e022c861a42677062dd015872aa16e4d45526d1
git-subtree-dir: packages/JSON git-subtree-split: 4b3913d58f04cc5bb2f8d23c6ef82e0fbed20525
git-subtree-dir: packages/CancellationTokens git-subtree-split: 9130370b57161b38d5a8b2bb0f947f60d7adc988
…CancellationTokens'
|
Hi @davidanthoff! I saw your message on Slack, I am interested in helping however I can, hope you don't mind me asking a few questions. a) if SymbolServer supports multiple env, it would enable a full workspace resolution including test/, docs/ and ext/, is that correct? b) In which case a follow-up question is is there a conflict between symbols when there are developed packages? If I'm not wrong, SymbolServer does index developed packages, but atm there is no resolution (go to definition) outside of the package's env. If there is an additional process for test/ for example, then should SymbolServer return the developed package's symbol or the registry's version if it exists? Maybe I'm misunderstanding how SymbolServer works and there is no conflict. |
I'm not sure this will work out, but so far it seems fairly promising. The idea is that we just move the existing content of both packages in here so simplify development.
I also started to change StaticLint so that everything in the
metafield inEXPRis now stored in a side table, that makes everything work fairly nicely with the functional Salsa.jl approach.Still lots of stuff to do, though...