Emit data::Impl in save-analysis #47657

algesten · 2018-01-22T15:35:16Z

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 derive Hash for ImplKind enum.~~

rust-highfive · 2018-01-22T15:35:32Z

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 · 2018-01-22T15:37:57Z

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

jonhoo · 2018-01-22T15:59:31Z

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

algesten · 2018-01-22T15:59:50Z

r? @nrc

algesten · 2018-01-22T16:00:39Z

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

shepmaster · 2018-01-26T18:42:14Z

Ping from triage, @nrc!

nrc · 2018-01-29T06:47:42Z

src/librustc_save_analysis/lib.rs

@@ -1088,6 +1139,7 @@ pub fn process_crate<'l, 'tcx, H: SaveHandler>(
            analysis,
            span_utils: SpanUtils::new(&tcx.sess),
            config: find_config(config),
+            impl_counter: Cell::new(0_u32),


You shouldn't need the _u32 here

nrc · 2018-01-29T06:49:06Z

src/librustc_save_analysis/dump_visitor.rs

-            self.dumper.dump_relation(impl_data);
+            if let super::Data::RelationData(rel, imp) = impl_data {
+                self.dumper.dump_relation(rel);
+                self.dumper.dump_impl(imp);


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

@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 · 2018-01-29T06:51:35Z

src/librustc_save_analysis/lib.rs

+                            kind: kind,
+                            span: span,
+                            value: String::new(),     // ???
+                            parent: None,             // ??? enclosing module?


Yes, this should be the enclosing module

@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 · 2018-01-29T06:51:53Z

src/librustc_save_analysis/lib.rs

+                            id: impl_id,
+                            kind: kind,
+                            span: span,
+                            value: String::new(),     // ???


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

nrc · 2018-01-29T06:53:03Z

src/librustc_save_analysis/lib.rs

+                                .collect(),
+                            docs: "".to_string(),     // ??? trait docs?
+                            sig: None,                // ??? trait sig?
+                            attributes: vec![],       // ??? trait attrs?


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).

@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 · 2018-01-29T07:00:22Z

src/librustc_save_analysis/lib.rs

+        let hash = hasher.finish();
+
+        // is this a good idea?
+        (hash ^ hash << 32) as u32


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 · 2018-01-29T07:03:01Z

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 · 2018-01-29T07:21:59Z

Ok. I remove the hashing.

nrc · 2018-02-01T02:47:51Z

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 · 2018-02-01T17:12:51Z

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 · 2018-02-01T17:14:53Z

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

algesten · 2018-02-01T17:15:11Z

Hm. maybe i rebase..

nrc · 2018-02-02T03:12:54Z

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 · 2018-02-02T07:27:05Z

Oh. I check.

algesten · 2018-02-02T07:31:47Z

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

algesten · 2018-02-02T07:32:08Z

and rebased off master again.

nrc · 2018-02-05T05:42:02Z

Thanks!

@bors: r+

bors · 2018-02-05T05:42:03Z

📌 Commit 38c517c has been approved by nrc

bors · 2018-02-05T09:16:57Z

🔒 Merge conflict

algesten · 2018-02-05T11:39:44Z

@nrc do i rebase off master again?

kennytm · 2018-02-05T13:16:47Z

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

kennytm · 2018-02-07T22:47:46Z

Why this PR is always merge-conflicting 😂

(Please rebase again)

algesten · 2018-02-10T02:05:24Z

Done

shepmaster · 2018-02-10T02:11:25Z

@bors r=nrc

bors · 2018-02-10T02:11:25Z

📌 Commit 9a6afa8 has been approved by nrc

bors · 2018-02-10T05:42:57Z

⌛ Testing commit 9a6afa8 with merge eb0fdb6...

Emit data::Impl in save-analysis As discussed on [internals.rust-lang](https://internals.rust-lang.org/t/rustdoc2-rls-analysis-and-the-compiler-help-wanted/6592/5), this PR emits `rls-data::Impl` in the save-analysis. A number of questions are outstanding: - [x] 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?~~ - [x] Need a new rls-data with an `id` field in `Impl` struct. - [ ] ~~Need a new rls-data which `derive` `Hash` for `ImplKind` enum.~~

bors · 2018-02-10T07:28:51Z

💔 Test failed - status-appveyor

kennytm · 2018-02-10T07:49:53Z

@bors retry #48116

bors · 2018-02-11T05:29:26Z

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

Emit data::Impl in save-analysis As discussed on [internals.rust-lang](https://internals.rust-lang.org/t/rustdoc2-rls-analysis-and-the-compiler-help-wanted/6592/5), this PR emits `rls-data::Impl` in the save-analysis. A number of questions are outstanding: - [x] 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?~~ - [x] Need a new rls-data with an `id` field in `Impl` struct. - [ ] ~~Need a new rls-data which `derive` `Hash` for `ImplKind` enum.~~

bors · 2018-02-11T08:21:24Z

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

@nrc

Tested on commit rust-lang/rust@0bb8935. 💔 rls on windows: test-pass → test-fail (cc @nrc). 💔 rls on linux: test-pass → test-fail (cc @nrc).

kennytm · 2018-02-11T08:34:41Z

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

[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 · 2018-02-11T20:01:14Z

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

rust-highfive assigned nikomatsakis Jan 22, 2018

algesten mentioned this pull request Jan 22, 2018

Updates for save-analysis rust-dev-tools/rls-data#14

Merged

rust-highfive assigned nrc and unassigned nikomatsakis Jan 22, 2018

carols10cents added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 22, 2018

nrc reviewed Jan 29, 2018

View reviewed changes

algesten force-pushed the save-analysis-impls branch from 8f033f1 to c7709fd Compare February 1, 2018 17:14

algesten force-pushed the save-analysis-impls branch from c7709fd to 93d3ebc Compare February 1, 2018 17:19

algesten force-pushed the save-analysis-impls branch from 93d3ebc to 38c517c Compare February 2, 2018 07:31

bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Feb 7, 2018

Emit data::Impl in save-analysis

9a6afa8

algesten force-pushed the save-analysis-impls branch from f70dddd to 9a6afa8 Compare February 10, 2018 02:05

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 10, 2018

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 10, 2018

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 10, 2018

kennytm mentioned this pull request Feb 10, 2018

Spurious (?) error in "compile-fail\rfc-2126-extern-in-paths\single-segment.rs" etc #48116

Closed

alexcrichton mentioned this pull request Feb 10, 2018

rustc: Upgrade to LLVM 6 #47828

Merged

bors merged commit 9a6afa8 into rust-lang:master Feb 11, 2018

This was referenced Feb 11, 2018

Fix how paths are printed by error messages during bootstrap #47731

Closed

Relax termination_trait's error bound #47544

Merged

algesten deleted the save-analysis-impls branch March 3, 2018 09:48

algesten mentioned this pull request Mar 4, 2018

[wip] Expand Impl API rust-dev-tools/rls-analysis#131

Closed

Emit data::Impl in save-analysis #47657

Emit data::Impl in save-analysis #47657

Conversation

algesten commented Jan 22, 2018 • edited Loading

rust-highfive commented Jan 22, 2018

algesten commented Jan 22, 2018

jonhoo commented Jan 22, 2018

algesten commented Jan 22, 2018

algesten commented Jan 22, 2018

shepmaster commented Jan 26, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nrc commented Jan 29, 2018

algesten commented Jan 29, 2018

nrc commented Feb 1, 2018

algesten commented Feb 1, 2018

algesten commented Feb 1, 2018

algesten commented Feb 1, 2018

nrc commented Feb 2, 2018

algesten commented Feb 2, 2018

algesten commented Feb 2, 2018

algesten commented Feb 2, 2018

nrc commented Feb 5, 2018

bors commented Feb 5, 2018

bors commented Feb 5, 2018

algesten commented Feb 5, 2018

kennytm commented Feb 5, 2018

kennytm commented Feb 7, 2018 • edited Loading

algesten commented Feb 10, 2018

shepmaster commented Feb 10, 2018

bors commented Feb 10, 2018

bors commented Feb 10, 2018

bors commented Feb 10, 2018

kennytm commented Feb 10, 2018

bors commented Feb 11, 2018

bors commented Feb 11, 2018

kennytm commented Feb 11, 2018

nrc commented Feb 11, 2018

algesten commented Jan 22, 2018 •

edited

Loading

kennytm commented Feb 7, 2018 •

edited

Loading