Emit data::Impl in save-analysis

[algesten]

As discussed on internals.rust-lang, this PR emits rls-data::Impl in the save-analysis.

A number of questions are outstanding:

• A few ??? around row 356. We need to discuss what goes here, if anything.
• Deriving id for impl using hashing. Is this going to clash with rustc defids?
• Deriving id for impl using hashing. Is the conversion from 64 bit -> 32 bit problematic?
• Need a new rls-data with an id field in Impl struct.
• Need a new rls-data which deriveHash for ImplKind enum.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[algesten]

It's specifically @nrc that needs to look at this PR to guide me in completing the work.

[jonhoo]

@algesten you can make that happen by writing r? @nrc

[algesten]

r? @nrc

[algesten]

Thanks @jonhoo I was aware of the feature but unsure whether it applied to wip stuff.

[shepmaster]

Ping from triage, @nrc!

[nrc]

You shouldn't need the _u32 here

[nrc]

Using the cast macro rather than if let here is preferred.

[algesten]

@nrc but the cast macro is written for super::Data enclosing one value. Since this is the only data emitting two values, I though it cleaner make this an exeption rather than changing the macro to handle a tuple as well.

[nrc]

ok

[nrc]

Yes, this should be the enclosing module

[algesten]

Ok i fix.

[algesten]

@nrc sorry I feel stupid here. can I actually get the parent module? All other match arms of ast::ImplKind set parent: None. Is this case different?

[nrc]

This is fine (I don't think we'll ever use it)

[nrc]

There might be attributes on the impl that should be recorded here (I think). We don't need anything else. For docs and sig, we can leave them as they are (though I would prefer to use only one way to make an empty string).

[algesten]

I fix

[algesten]

@nrc Unless I'm looking in the wrong place, there doesn't seem to be any attrs on the Impl level (there are on the ImplItem level).

https://manishearth.github.io/rust-internals-docs/syntax/ast/enum.ItemKind.html

[nrc]

You can just use the 64 bit hash - iirc, we use 32 bits for a local id (NodeId) and 64 for a global id (DefId)

[nrc]

So, having thought this through a little bit, I think the hashing scheme might be overkill (sorry). We could just use the count of impls as the id, as long as clients ensure that impl ids are in a separate namespace from other ids, then I think everything will be OK (and that should be OK, since impl ids and def ids are not interchangeable).

[algesten]

Ok. I remove the hashing.

[nrc]

OK, this all looks. I've merged your changes to rls-data and released that as version 0.15. Could you also squash your commits please?

[algesten]

Here's the new output. It looks ok.

{
"impls": [
{
"id": 0,
"kind": "Direct",
"span": {
"file_name": [
115,
114,
99,
47,
109,
97,
105,
110,
46,
114,
115
],
"byte_start": 234,
"byte_end": 242,
"line_start": 15,
"line_end": 15,
"column_start": 22,
"column_end": 30
},
"value": "",
"parent": null,
"children": [
{
"krate": 0,
"index": 22
},
{
"krate": 0,
"index": 24
}
],
"docs": "",
"sig": null,
"attributes": []
}
]
}

[algesten]

@nrc I've updated to rls-data 0.15 and squashed the commits.

[algesten]

Hm. maybe i rebase..

[nrc]

I think you don't want to change the submodules which are included in this PR? But you probably do need to build (and maybe update) in order to get rls-data 0.15 into the Cargo.lock

[algesten]

Oh. I check.

[algesten]

@nrc sorted. submodule free and one Cargo.lock.

[algesten]

and rebased off master again.

[nrc]

Thanks!

@bors: r+

[bors]

📌 Commit 38c517c has been approved by nrc

[bors]

🔒 Merge conflict

[algesten]

@nrc do i rebase off master again?

[kennytm]

@algesten Yes please rebase. Also, remove the [wip] from the title if it is ready for merging.

[kennytm]

Why this PR is always merge-conflicting 😂

(Please rebase again)

[algesten]

Done

[shepmaster]

@bors r=nrc

[bors]

📌 Commit 9a6afa8 has been approved by nrc

[bors]

⌛ Testing commit 9a6afa8 with merge eb0fdb6...

[bors]

💔 Test failed - status-appveyor

[kennytm]

@bors retry #48116

[bors]

⌛ Testing commit 9a6afa8 with merge 0bb8935...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nrc
Pushing 0bb8935 to master...

[kennytm]

@nrc@algesten FYI the rls tests failed on this PR.

Details

[01:26:35] failures:
[01:26:35] [01:26:35] ---- test::test_find_impls stdout ----
[01:26:35] expect_messages:
[01:26:35] results: [
[01:26:35] "{\"jsonrpc\":\"2.0\",\"id\":0,\"result\":{\"capabilities\":{\"textDocumentSync\":2,\"hoverProvider\":true,\"completionProvider\":{\"resolveProvider\":true,\"triggerCharacters\":[\".\",\":\"]},\"definitionProvider\":true,\"referencesProvider\":true,\"documentHighlightProvider\":true,\"documentSymbolProvider\":true,\"workspaceSymbolProvider\":true,\"codeActionProvider\":true,\"documentFormattingProvider\":true,\"documentRangeFormattingProvider\":false,\"renameProvider\":true,\"executeCommandProvider\":{\"commands\":[\"rls.applySuggestion\",\"rls.deglobImports\"]}}}}",
[01:26:35] "{\"jsonrpc\":\"2.0\",\"method\":\"rustDocument/beginBuild\"}",
[01:26:35] "{\"jsonrpc\":\"2.0\",\"method\":\"rustDocument/diagnosticsBegin\"}",
[01:26:35] "{\"jsonrpc\":\"2.0\",\"method\":\"rustDocument/diagnosticsEnd\"}"
[01:26:35] ],
[01:26:35] expected: [
[01:26:35] ExpectedMessage {
[01:26:35] id: Some(
[01:26:35] 0
[01:26:35] ),
[01:26:35] contains: [
[01:26:35] "capabilities"
[01:26:35] ]
[01:26:35] },
[01:26:35] ExpectedMessage {
[01:26:35] id: None,
[01:26:35] contains: [
[01:26:35] "beginBuild"
[01:26:35] ]
[01:26:35] },
[01:26:35] ExpectedMessage {
[01:26:35] id: None,
[01:26:35] contains: [
[01:26:35] "diagnosticsBegin"
[01:26:35] ]
[01:26:35] },
[01:26:35] ExpectedMessage {
[01:26:35] id: None,
[01:26:35] contains: [
[01:26:35] "diagnosticsEnd"
[01:26:35] ]
[01:26:35] }
[01:26:35] ]
[01:26:35] expect_messages:
[01:26:35] results: [
[01:26:35] "{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":[{\"uri\":\"file:///checkout/src/tools/rls/test_data/find_impls/src/main.rs\",\"range\":{\"start\":{\"line\":18,\"character\":15},\"end\":{\"line\":18,\"character\":18}}}]}"
[01:26:35] ],
[01:26:35] expected: [
[01:26:35] ExpectedMessage {
[01:26:35] id: Some(
[01:26:35] 1
[01:26:35] ),
[01:26:35] contains: [
[01:26:35] "\"range\":{\"start\":{\"line\":18,\"character\":15},\"end\":{\"line\":18,\"character\":18}}",
[01:26:35] "\"range\":{\"start\":{\"line\":19,\"character\":12},\"end\":{\"line\":19,\"character\":15}}"
[01:26:35] ]
[01:26:35] }
[01:26:35] ]
[01:26:35] thread 'test::test_find_impls' panicked at 'Could not find `"range":{"start":{"line":19,"character":12},"end":{"line":19,"character":15}}` in `{"jsonrpc":"2.0","id":1,"result":[{"uri":"file:///checkout/src/tools/rls/test_data/find_impls/src/main.rs","range":{"start":{"line":18,"character":15},"end":{"line":18,"character":18}}}]}`', libcore/option.rs:917:5
[01:26:35] note: Run with `RUST_BACKTRACE=1` for a backtrace.
[01:26:35] [01:26:35] [01:26:35] failures:
[01:26:35] test::test_find_impls
[01:26:35] [01:26:35] test result: FAILED. 39 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
[01:26:35] [01:26:35] error: test failed, to rerun pass '--bin rls'

[nrc]

@kennytm this is expected (I think) and should be solved by updating the RLS and then updating the version in the Repo