Always calculate glob map but only for glob uses
Previously calculating glob map was *opt-in*, however it did record node id -> ident use for every use directive. This aims to see if we can unconditionally calculate the glob map and not regress performance.
Main motivation is to get rid of some of the moving pieces and simplify the compilation interface - this would allow us to entirely remove `CrateAnalysis`. Later, we could easily expose a relevant query, similar to the likes of `maybe_unused_trait_import` (so using precomputed data from the resolver, but which could be rewritten to be on-demand).
r? @nikomatsakis
Local perf run showed mostly noise (except `ctfe-stress-*`) but I'd appreciate if we could do a perf run run here and double-check that this won't regress performance.
Previously calculating glob map was *opt-in*, however it did record
node id -> ident use for every use directive. This aims to see if we
can unconditionally calculate the glob map and not regress performance.
save-analysis: Get path def from parent in case there's no def for the path itself.
This fixes#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.
This fixes#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.
Prefer unwrap_or_else to unwrap_or in case of function calls/allocations
The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`.
An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).
Various small diagnostic and code clean up
- Point at def span on incorrect `panic` or `oom` function
- Use structured suggestion instead of note for `+=` that can be performed on a dereference of the left binding
- Small code formatting cleanup
refactor match guard
This is the first step to implement RFC 2294: if-let-guard. Tracking issue: https://github.com/rust-lang/rust/issues/51114
The second step should be introducing another variant `IfLet` in the Guard enum. I separated them into 2 PRs for the convenience of reviewers.
r? @petrochenkov
