-
Notifications
You must be signed in to change notification settings - Fork 413
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
[Feature Request]: CLS: add global constants/functions to completion suggestions #24743
Comments
Hi, thanks for opening the issue! My feeling is that this request is in two parts.
The former can be made to work today with relative ease. The latter is a bit more challenging. Today, CLS works by looking at the saved version of the file, largely because the parser isn't very good at recognizing partial programs. If you write: var x = Locales. It doesn't know what to do with that program, so it's difficult to provide intelligent suggestions. So, code completion based on context, such as 'what's on the left of the |
Hi ! Indeed, this can be seen as two incremental parts. Just having the global symbols would be very useful to beginners in the language (such as me 😃). I initially thought CLS was able to generate suggestions based on type information, for instance with the following program, const D = {1..10};
var A: [D] real;
A.<next LSP suggestion> CLS could propose |
…gest autocompletion (#24776) Should fix #24743. This PR beefs up CLS's ability to find symbols in imported modules. It does so by: * Transitively searching for visible symbols instead when modules are imported. This means that if module `A` re-exports variables from module `B`, importing `A` will make `B`'s variables appear in completions. * Ensuring that auto modules, in addition to regular modules, are considered for auto-completion. These are the modules that bring in `Locale`, `here`, and all others. Prior to this, Dyno did not have a way to collect _all_ visible symbols (opting instead for per-symbol lookups). Thus, this PR adds the corresponding Dyno query (memoization and all). This PR does _not_ address the `Locales.size` aspect of #24743, as this relies on parser improvements and type resolution (the former being not-yet-started, the latter being experimental and unstable). Only completions for global variables such as `Locales` are present. Reviewed by @jabraham17 -- thanks!
Oops, I didn't mean to auto-close this. @ninivert -- we just recently merged a PR that addresses the 'global symbols' part of your issue ( Since this original issue is largely about global symbols, I would be inclined to close it, and open another for methods / fields of types (i.e., |
Thank you @DanilaFe ! I was eyeing that PR, thank you for your time ; I will check it out later today (edit : I can confirm it works ! 🎉 ). Yes I think it's reasonable to open another issue for the methods / fields of types. |
I've opened #24836 to track the follow-up issue. Thanks again for reporting the issue and validating that it works. And of course, thanks for trying out Chapel! |
Summary of Feature
When starting from an empty file,
chpl-language-server
should show the globally available symbols when prompted for suggestions, for instance:numLocales
,Locales
,here
, ...writeln
,write
,warning
, ...In the VSCode extension, some of these are made available through snippets: https://github.com/chapel-lang/chapel-vscode/blob/main/snippets/chapel.json
Code Sample
Writing the above code would be much faster with this feature.
Currently
Locales.
<next LSP suggestion> yields nothing from CLS, where I would expect methods to be available on the array of locales.The text was updated successfully, but these errors were encountered: