Simplify hir::PathSegment

[nnethercote]

r? @petrochenkov

[rustbot]

Some changes occurred in need_type_info.rs

cc @lcnr

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[nnethercote]

Best reviewed one commit at a time.

I'm not sure if removing the Options is a good idea or not. But I did measurements and found that over 90% of PathSegments had both the hir_id and the res, so it seems like they might as well be mandatory. Let me know what you think.

[petrochenkov]

I think it's a good idea, since these IDs and resolutions are already actively used by lints and similar, it's better to make sure that they are always set.

[nnethercote]

I have addressed the review comments.

[petrochenkov]

@bors r+

[bors]

📌 Commit 11020f1 has been approved by petrochenkov

It is now in the queue for this repository.

[Dylan-DPC]

failed in rollup

@bors r-

[nnethercote]

I fixed the rollup failure.

[nnethercote]

@bors r=petrochenkov

[bors]

📌 Commit 08a00eb has been approved by petrochenkov

It is now in the queue for this repository.

[bors]

⌛ Testing commit 08a00eb with merge 2dc703f...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 2dc703f to master...

[rust-timer]

Finished benchmarking commit (2dc703f): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	0.7%	[0.3%, 1.3%]	16
Regressions ❌ (secondary)	1.3%	[0.9%, 1.8%]	14
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.3%, 1.3%]	16

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.6%	[4.6%, 4.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.8%	[-1.8%, -1.8%]	1
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Footnotes

1. the arithmetic mean of the percent change ↩ ↩²

2. number of relevant changes ↩ ↩²

[nnethercote]

Weird regressions here. I did some downloads and diffs with Cachegrind. The tt-muncher and html5ever-0.26.0 ones are due to changes in parse_tt, which this PR didn't touch, but which is hot and I think somewhat prone to perturbations due to minor changes. The keccak one is due to process_obligations, which is also hot and prone to perturbations. And I didn't expect the changes in this PR to have much effect, it really wasn't changing things much.

[nnethercote]

Some evidence here that these apparent regressions weren't real.

[nnethercote]

@rustbot label: +perf-regression-triaged