-
Notifications
You must be signed in to change notification settings - Fork 125
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
feat: definitions and references lsp hint #1016
Conversation
Also this would enable semantic highlighting I think? |
Consider using
I think we should do it for this new code and retroactively do it for the inactive code hints too. Probably good to compartmentalize the bulk of the new stuff into a new module. We could make the functions always be called, and then the function body can be conditionally compiled (with an empty body by default); and rely on dead code elimination to do the right thing. Or add conditional compilation at the call-site to guarantee the optimization. |
c2099f9
to
7b0ff8d
Compare
f97183a
to
df047ee
Compare
parser/src/cfg/mod.rs
Outdated
.push_from_atom(atom); | ||
vkey_expr | ||
.atom(s.vars()) | ||
.expect("must be atom since we're matching atom") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fly-by comment
The way this new code works isn't right because match
ing an expr and finding an Atom
might find you a $var
that is actually a list.
You might want to add span_atom
equivalent of span_list
, which I haven't yet added because I didn't have the need for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. I've refactored in 99be6a2. No need for span_atom
This also fixes wasm build. Also simplify main.rs.
Also: - fix misleading error message when list after deflayermap token is empty. - capture only layer name in deflayer/deflayermap. Previously it captured span of a list where layer name is defined
one problematic aspect of implementing defs/refs for variables is that there are 2 types of variables: normal (globally scoped) variables, and variables in Edit: I'd say let's just ignore existence of template variables from perspective of refs/defs. |
implementing for chord groups doesn't seem that important, but another cool thing about defs/refs hints is that it also will allow implementing semantic highlighting |
Also adds "lsp" cargo feature. TODO: conditionally compile all lsp-related features behind this flag
I've implemented defs/refs for variables.
To minimize amount of changes and taking into consideration that it will be used only with "lsp" cargo flag, I think it's pretty reasonable to go for something like a global What do you think @jtroo? |
Let's just ignore them for now, they don't seem to be important for goto definition. It can always be added later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've implemented defs/refs for variables.
...
To minimize amount of changes and taking into consideration that it will be used only with "lsp" cargo flag, I think it's pretty reasonable to go for something like a globalstatic mut
variable.
The higher-level idea is sensible. The current implementation needs to be changed though; static mut
is rarely if ever correct to do. The idea can be implemented without unsafe, and so should be. The parser is not multi-threaded, so one option is to use thread_local. Using thread_local
also means parser+lsp tests should be able to be run in parallel just.
Although due to how str_to_oscode
works, parser tests already shouldn't run in parallel anyway, so another option is to use Lazy<Mutex<...>>
like how CUSTOM_STRS_TO_OSCODES
does it.
|
Done. Not sure if I'm using it correctly, but seems to work. |
I recall (perhaps incorrectly) that there are other threads other than the one the parser runs on for the real Kanata program. If I'm correct, using thread_local would mean the other threads do not see results from deflocalkeys, which would be incorrect behaviour. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs a bit more cleanup and refining around conditional compilation; once that's done will be good to merge.
parser/src/cfg/platform.rs
Outdated
@@ -138,7 +138,7 @@ pub(crate) fn filter_env_specific_cfg( | |||
env_var_val.is_empty(), | |||
) { | |||
(None, false) => { | |||
lsp_hint_inactive_code.push(LspHintInactiveCode { | |||
lsp_hint_inactive_code.push(lsp_hints::InactiveCode { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add the conditional compilation with LSP here as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Describe your changes. Use imperative present tense.
Add goto definition support for LSP consumers. Adding support for it directly in LSP server could maybe be doable, but unreliable (e.g. templates are complicating things) and so a lot of parser logic would need to be reimplemented for all edge cases, so I think this is better added directly to kanata-parser.
For now I've added definition and references for aliases. I'd like to wait for recieve some feeback (i.e. if this is a direction we want to take) before adding the rest (variables, layers, etc.).
Currently the code is working for aliases when paired with rszyma/vscode-kanata#32
Implementation notes:
I couldn't add
lsp_hints
toParserState
, because it would require changing&
to&mut
ons
param in many places which would be really ugly, and even then, when trying to switch to&mut
at some point I got an error regarding multiple borrows of&mut s
at the same time. So instead I've added additionallsp_hints
param to many functions.Other done things:
lsp_hint_inactive_code
fromParserState
toIntermediateConfig
Other thoughts:
Perhaps for performance purposes LSP features could be behind a feature flag, but it doesn't seem like it causes any major performance degradation + parser code runs only once, so for simplicity I didn't introduce the flag.
Checklist 1
Go-to definition and references implemented for:
chord_groupsChecklist 2