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

When enum variant is missing import, it should contain the enum's span #5188

Open
sdankel opened this issue Oct 13, 2023 · 0 comments
Open
Labels
bug Something isn't working compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen language server LSP server

Comments

@sdankel
Copy link
Member

sdankel commented Oct 13, 2023

In this example, the enum DeepEnum is not imported. When it's just the enum specified, the compiler diagnostic correctly reports the enum's span. However, when a variant of the enum is specified, the variant's span is specified. In both cases, it should be the enum's span, never the variant's span.

This is relevant to LSP because we need use the diagnostic's span to determine which symbol needs to be imported (for auto-import suggestions).

    let a: DeepEnum = DeepEnum::Variant;
image
@sdankel sdankel added bug Something isn't working language server LSP server compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen labels Oct 13, 2023
IGI-111 pushed a commit that referenced this issue Oct 20, 2023
## Description

Closes #4782

Notes

This implementation relies on the diagnostics that are provided in the
context of a code action request. Conveniently, only the diagnostics
related to the symbol in the request are provided in the context. Since
we also need the name of the symbol to look up, I added a
`DiagnosticData` type to the metadata that is published with
diagnostics. For the errors that indicate a missing symbol, this data is
attached, and then used to look for possible imports when the code
action request handler runs.

- Added `ProgramTypeKeyword` symbol kind to distinguish them from other
keywords
- Added `submodules_recursive` to lexed and parsed modules because LSP
wasn't collecting tokens inside of nested submodules. This
implementation comes from typed module, I just made it generic via the
`HasSubmodules` and `HasModule` traits.
- Added `TyIncludeStatement` to the compiler, and span and mod_name to
`IncludeStatement` to populate it. This was needed to identify where the
end of the last `mod` statement is in the file.
- Added `span` to `UseStatment` and `TyUseStatement` so that we can
replace an entire Group statement with the new one. e.g. `use a::b::{C,
D, E};`
- Added `CallPath` to several of the typed tokens that were missing it.

### Testing

- integration tests for each type of item that can be imported
- unit tests for the location of the generated import in the file

### Limitations

I found several bugs / edge cases where auto-import doesn't work:
- enum variants: #5188 
- std-lib functions: #5191
- std-lib constants: #5192

## Checklist

- [ ] I have linked to any relevant issues.
- [ ] I have commented my code, particularly in hard-to-understand
areas.
- [ ] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [ ] I have added tests that prove my fix is effective or that my
feature works.
- [ ] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [ ] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [ ] I have requested a review from the relevant team or maintainers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working compiler: frontend Everything to do with type checking, control flow analysis, and everything between parsing and IRgen language server LSP server
Projects
None yet
Development

No branches or pull requests

1 participant