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

Fix diagnostic fixes showing up everywhere #253

Merged
merged 1 commit into from
Dec 5, 2018

Conversation

flodiebold
Copy link
Member

The LSP code action request always returned the fixes for all diagnostics anywhere in the file, because of a shadowed variable.

There's no test yet; I wasn't sure where to add it. I tried adding one in heavy_tests, but that's a bit uncomfortable because the code action response contains the (random) file paths. I could make it work, but wanted to ask beforehand what you think.

The LSP code action request always returned the fixes for all diagnostics
anywhere in the file, because of a shadowed variable.
@matklad
Copy link
Member

matklad commented Dec 4, 2018

Excellent catch!

As for the testing, I am not quite sure myself.

I think it makes sense to write a small amount of integration tests for ra_lsp_server: it's mostly glue code, all corner-cases should be handled lower in the stack, and we really need to check only for blunders like this one.

That probably means that yes, we need a heavy test here.

OTOH, I am not entirely sure that heavy tests is the right approach here. A possible alternative would be to write a client-side test (that is, spawn a headless vs code process, spawn an lsp_server binary, etc). This seems more trustworthy, b/c it actually tests interaction between the client and the server, but it should be hard to write reliably: we need to do some contortions (internal_mode) to synchronize the heavy_test, syncing different processes will be a massive pain I guess.

All things considered, using heavy tests for the time being seems like the best option. The "file names are not determenistic" problem should be solved by improving the test fixture. The way we solve this in Cargo is that you can use [..] in the output to match any substring.

Here's the code that does this: https://github.com/rust-lang/cargo/blob/485670b3983b52289a2f353d589c57fae2f60f82/tests/testsuite/support/mod.rs#L1223-L1276

I suggest copy-pasting it to the test-utils crate, or, better, fishing on crates.io for something which allows to approximately compare JSON.

@matklad
Copy link
Member

matklad commented Dec 5, 2018

Let's merge this as is for now, but a test would be very welcome here!

bors r+

bors bot added a commit that referenced this pull request Dec 5, 2018
253: Fix diagnostic fixes showing up everywhere r=matklad a=flodiebold

The LSP code action request always returned the fixes for all diagnostics anywhere in the file, because of a shadowed variable.


There's no test yet; I wasn't sure where to add it. I tried adding one in `heavy_tests`, but that's a bit uncomfortable because the code action response contains the (random) file paths. I could make it work, but wanted to ask beforehand what you think.

256: Improve/add use_item documentation r=matklad a=DJMcNab

Adds some documentation to use_item explaining all code paths (use imports are hard, especially with the ongoing discussion of anchored v. uniform paths - see rust-lang/rust#55618 for what appears to be the latest developments)

Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: DJMcNab <36049421+djmcnab@users.noreply.github.com>
@bors
Copy link
Contributor

bors bot commented Dec 5, 2018

Build failed (retrying...)

bors bot added a commit that referenced this pull request Dec 5, 2018
253: Fix diagnostic fixes showing up everywhere r=matklad a=flodiebold

The LSP code action request always returned the fixes for all diagnostics anywhere in the file, because of a shadowed variable.


There's no test yet; I wasn't sure where to add it. I tried adding one in `heavy_tests`, but that's a bit uncomfortable because the code action response contains the (random) file paths. I could make it work, but wanted to ask beforehand what you think.

Co-authored-by: Florian Diebold <flodiebold@gmail.com>
@bors
Copy link
Contributor

bors bot commented Dec 5, 2018

Build succeeded

@bors bors bot merged commit d0811c4 into rust-lang:master Dec 5, 2018
@flodiebold flodiebold deleted the code-action-location branch February 24, 2019 21:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants