Shorten some dependency chains in the compiler

[joshtriplett]

(I recommend reviewing this commit by commit.)

One of the long dependency chains in the compiler is:

• Many things depend on rustc_errors.
• rustc_errors depended on many things prior to this PR, including rustc_target, rustc_type_ir, rustc_hir, and rustc_lint_defs.
• rustc_lint_defs depended on rustc_hir prior to this PR.
• rustc_hir depends on rustc_target.
• rustc_target is large and takes a while.

This PR breaks that chain, through a few steps:

• The IntoDiagArgs trait, from rustc_errors, moves earlier in the dependency chain. This allows rustc_errors to stop depending on a pile of crates just to implement IntoDiagArgs for their types.
• Split rustc_hir_id out of rustc_hir, so crates that just need HirId and similar don't depend on all of rust_hir (and thus rustc_target).
• Make rustc_lint_defs stop depending on rustc_hir.

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

These commits modify compiler targets.
(See the Target Tier Policy.)

rustc_error_messages was changed

cc @davidtwco, @compiler-errors, @TaKO8Ki

[joshtriplett]

@bors try @rust-timer queue

[joshtriplett]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0847c11 (0847c1164841cdb4610f0754850945481c8e48ff, parent: 2c1ac85679678dfe5cce7ea8037735b0349ceaf3)

[Kobzol]

(Not sure if we'll see any changes in the bootstrap timings for this, because bootstrap is benchmarked with -j1, so all crates are compiled serially).

[rust-timer]

Finished benchmarking commit (0847c11): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	4.7%	[4.7%, 4.7%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.4%	[-0.2%, 4.7%]	3

Max RSS (memory usage)

Results (primary -1.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.9%	[2.9%, 2.9%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-5.7%	[-5.7%, -5.7%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.4%	[-5.7%, 2.9%]	2

Cycles

Results (primary 3.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.8%	[3.8%, 3.8%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.8%	[3.8%, 3.8%]	1

Binary size

Results (primary 0.1%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.3%, 0.3%]	3
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	2
Improvements ✅ (primary)	-0.0%	[-0.0%, -0.0%]	7
Improvements ✅ (secondary)	-0.1%	[-0.2%, -0.0%]	7
All ❌✅ (primary)	0.1%	[-0.0%, 0.3%]	10

Bootstrap: 470.224s -> 470.269s (0.01%)
Artifact size: 377.49 MiB -> 377.39 MiB (-0.03%)

[joshtriplett]

@Kobzol Fair enough. It's really the CI time that I'm hoping improves here, and that does normal parallel builds.

The clap_derive benchmark seems spurious. Does that seem likely to be noise, here?

[joshtriplett]

@rust-timer build 0847c11 include=clap_derive

[petrochenkov]

Why do rustc_errors and rustc_attr_parsing depend on HirId at all?
That doesn't look right to me from the design point of view.

[Kobzol]

@Kobzol Fair enough. It's really the CI time that I'm hoping improves here, and that does normal parallel builds.

The clap_derive benchmark seems spurious. Does that seem likely to be noise, here?

Yeah that's noise. (you can't perf. the same commit twice, btw 😅)

[bjorn3]

Why do rustc_errors and rustc_attr_parsing depend on HirId at all?
That doesn't look right to me from the design point of view.

rustc_attr_parsing needs the id of the item the attribute was applied to for calling tcx.emit_node_span_lint through a trait defined in rustc_errors.

[bors]

📌 Commit 8506be8 has been approved by lcnr

It is now in the queue for this repository.

[bjorn3]

@bors r-

Github says there is a merge conflict.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[joshtriplett]

Merge conflict fixed; can be re-queued once CI is green.

[joshtriplett]

@bors r=lcnr rollup

[bors]

📌 Commit 2ea7e7d has been approved by lcnr

It is now in the queue for this repository.