forked from chapel-lang/chapel
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
LSP: fix "call hierarchy" across files (chapel-lang#26040)
In the following program, trying to get the call hierarchy for `writeln` did not work on `main`. ```Chapel writeln("Hello, world!"); ``` There were a few issues with this. The first issue is that the the "index" that was fed through a `CallHierarchyItem` to LSP and back to `CLS` was an index into a single file's list of instantiations. Thus, if the function was instantiated in one place, but defined in another, the index would not be valid (or worse, be incorrect). This PR changes this by changing the way typed signatures are mapped to JSON-compatible identifiers; they are instead registered with a `ContextContainer` object, getting a unique ID. The unique ID is then used as JSON data, and can be used to access the same `TypedSignature` object when the JSON is being deserialized. This, however, was not enough. The next problem was that we currently create a new `ContextContainer` per file (to handle the case in which multiple files with the same name / module name exist). As a result of this, `writeln` that is called in module `A` and defined in module `B` will have its instantiation computed using `A`'s context, but its AST and other information will use `B`'s context. This is troublesome. This PR adjusts the situation by changing the `file -> FileInfo` mapping to be a `(file, context id) -> FileInfo` mapping. This way, the same file can have several contexts (e.g., if a standard library file is loaded from two distinct files, but both named `A.chpl`). By default (e.g., when opening a file), the `(file, "None")` key is used (since no particular context was requested). However, if a file A needs to show an instantiation (via file info) from file B, we create a new mapping `(fileB, fileA.context.id) -> fileInfoB`, which is created from the same context. This ensures that there is a file information object for file B with the same context as that of file A. When a call hierarchy item is constructed, it now specifies what context was used to create it. Thus, if other CallHierarchyItems point to other files, these other files are opened with the same context. To communicate the context over JSON, I employ the same approach as I did with typed signatures (register a context object with unique ID, use the ID to marshal the context to and from JSON). ~~To fix the case of `writeln` in particular, I had to relax an assertion from the `_owned`/`_shared_` resolution PR chapel-lang#25617. This led to some simplified code in any case, which is great. I believe @arezaii is fine with this change.~~ This was separately merged in chapel-lang#26078. A bug that I'm surprised we didn't find prior to this, which is fixed in this PR, is that vector unmarshalling for Python interop allocates a vector of the Python list's size, then pushes _additional elements_ instead of setting the already-allocated locations. This ended up e.g., pushing an empty string for each "real" string a user passed in a list. This led to some odd interactions with Dyno's module searching (an empty string as an input file led to "." being added to the module search path, which we do not want). Reviewed by @jabraham17 -- thanks! ## Testing - [x] LSP tests - [x] new call hierarchy tests - [x] dyno tests
- Loading branch information
Showing
6 changed files
with
344 additions
and
30 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.