Skip to content
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

Closed
ninivert opened this issue Apr 2, 2024 · 5 comments · Fixed by #24776
Closed

[Feature Request]: CLS: add global constants/functions to completion suggestions #24743

ninivert opened this issue Apr 2, 2024 · 5 comments · Fixed by #24776
Assignees
Labels
area: Python bindings For things related to chapel-py, chpl-language-server, chplcheck, etc. area: Tools type: Feature Request user issue

Comments

@ninivert
Copy link
Contributor

ninivert commented Apr 2, 2024

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, ...
  • probably others that I'm not aware of

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

writeln(numLocales, " should equal ", Locales.size);
write("hello world", '--- \n');

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.

@DanilaFe
Copy link
Contributor

DanilaFe commented Apr 2, 2024

Hi, thanks for opening the issue!

My feeling is that this request is in two parts.

  1. Make autocompletion aware of global symbols (e.g., numLocales, Locales, etc)
  2. Make autocompletion aware of fields on those types (e.g., Locales.<next LSP suggestion>).

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 .?', is a bit further off in the future.

@ninivert
Copy link
Contributor Author

ninivert commented Apr 2, 2024

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 rank, strides, size, etc. (from https://chapel-lang.org/docs/language/spec/arrays.html#predefined-routines-on-arrays), based on the fact it's an array (of reals). Unless I've messed up in setting up CLS, it seems this isn't yet available (so as you say, this would be the scope of another feature request)

@DanilaFe DanilaFe added the area: Python bindings For things related to chapel-py, chpl-language-server, chplcheck, etc. label Apr 5, 2024
DanilaFe added a commit that referenced this issue Apr 11, 2024
…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!
@DanilaFe
Copy link
Contributor

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 (Locales, numLocales, etc.). We haven't yet gotten support for Locale.size etc, since that's significantly more complicated, as we have discussed.

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., Locales.size, and really anything.anythingelse). Does that sound reasonable to you?

@DanilaFe DanilaFe reopened this Apr 11, 2024
@ninivert
Copy link
Contributor Author

ninivert commented Apr 11, 2024

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 can do this if it's helpful.

@DanilaFe
Copy link
Contributor

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Python bindings For things related to chapel-py, chpl-language-server, chplcheck, etc. area: Tools type: Feature Request user issue
Projects
None yet
3 participants