-
Notifications
You must be signed in to change notification settings - Fork 13.4k
save-analysis doesn't dump ref entry for struct name in static method calls #57462
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
/cc @nrc |
According to |
cc me |
I'm taking a look at this, fwiw. |
Oh, it's a bit more subtle, but I see what's going on now. |
I got a fix, testing to see if I can remove hacks to existing code now. |
Fix is at #57474, but it's unclear to me how to add a test for this. Any doc I could look at? |
This unfortunately passes regardless right now because of the racer fallback. And without the racer fallback we're not able to go to the definition of either Foo or Foo::new.
This unfortunately passes regardless right now because of the racer fallback. And without the racer fallback we're not able to go to the definition of either Foo or Foo::new. The test is probably worth having regardless.
…e path itself. This fixes rust-lang#57462. The relevant part from the hir type collector is: ``` DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(32) => Entry { parent: NodeId(33), dep_node: 4294967040, node: Expr(expr(32: <Foo>::new)) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(48) => Entry { parent: NodeId(32), dep_node: 4294967040, node: Ty(type(Foo)) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(30) => Entry { parent: NodeId(48), dep_node: 4294967040, node: PathSegment(PathSegment { ident: Foo#0, id: Some(NodeId(30)), def: Some(Err), args: None, infer_types: true }) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(31) => Entry { parent: NodeId(32), dep_node: 4294967040, node: PathSegment(PathSegment { ident: new#0, id: Some(NodeId(31)), def: Some(Err), args: None, infer_types: true }) } ``` We have the right ID when looking for NodeId(31) and try with NodeId(32) (which is the right thing to look for) from get_path_data, but not for the segments that we write from `write_sub_paths_truncated`. Basically `process_path` takes an id which is always the parent, and that we fall back to in `get_path_data()`, so we get the right result for the last path segment, but not for the other segments that get written to from `write_sub_paths_truncated`. I think we can stop passing the explicit id around to `get_path_data` now, will consider sending that as a followup.
save-analysis: Get path def from parent in case there's no def for the path itself. This fixes rust-lang#57462. The relevant part from the hir type collector is: ``` DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(32) => Entry { parent: NodeId(33), dep_node: 4294967040, node: Expr(expr(32: <Foo>::new)) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(48) => Entry { parent: NodeId(32), dep_node: 4294967040, node: Ty(type(Foo)) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(30) => Entry { parent: NodeId(48), dep_node: 4294967040, node: PathSegment(PathSegment { ident: Foo#0, id: Some(NodeId(30)), def: Some(Err), args: None, infer_types: true }) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(31) => Entry { parent: NodeId(32), dep_node: 4294967040, node: PathSegment(PathSegment { ident: new#0, id: Some(NodeId(31)), def: Some(Err), args: None, infer_types: true }) } ``` We have the right ID when looking for NodeId(31) and try with NodeId(32) (which is the right thing to look for) from get_path_data. But not when we look from `write_sub_paths_truncated` Basically process_path takes an id which is always the parent, and that we fall back to in get_path_data(), so we get the right result for the last path segment, but not for the other segments that get written to from write_sub_paths_truncated. I think we can stop passing the explicit `id` around to get_path_data as a followup.
save-analysis: Get path def from parent in case there's no def for the path itself. This fixes rust-lang#57462. The relevant part from the hir type collector is: ``` DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(32) => Entry { parent: NodeId(33), dep_node: 4294967040, node: Expr(expr(32: <Foo>::new)) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(48) => Entry { parent: NodeId(32), dep_node: 4294967040, node: Ty(type(Foo)) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(30) => Entry { parent: NodeId(48), dep_node: 4294967040, node: PathSegment(PathSegment { ident: Foo#0, id: Some(NodeId(30)), def: Some(Err), args: None, infer_types: true }) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(31) => Entry { parent: NodeId(32), dep_node: 4294967040, node: PathSegment(PathSegment { ident: new#0, id: Some(NodeId(31)), def: Some(Err), args: None, infer_types: true }) } ``` We have the right ID when looking for NodeId(31) and try with NodeId(32) (which is the right thing to look for) from get_path_data. But not when we look from `write_sub_paths_truncated` Basically process_path takes an id which is always the parent, and that we fall back to in get_path_data(), so we get the right result for the last path segment, but not for the other segments that get written to from write_sub_paths_truncated. I think we can stop passing the explicit `id` around to get_path_data as a followup.
tests: Add a test for rust-lang/rust#57462 and go-to-definition without racer in general.
Here's a small testcase:
If you run this through
rustc -Z save-analysis
and look at the save-analysis JSON file, you'll see that there is no entry for theFoo
part ofFoo::new()
. This seems like a bug.The text was updated successfully, but these errors were encountered: