Stop bailing out from compilation just because there were incoherent traits

[oli-obk]

fixes #120343

but also has a lot of "type annotations needed" fallout. Some are fixed in the second commit.

r? @nnethercote

(rustbot has picked a reviewer for you, use r? to override)

That's a lot of error output changes for such small compiler changes. I'm uncomfortable reviewing this because I know very little about trait stuff in general.

r? @lcnr

(or anyone else who might want to steal it, such as @compiler-errors or @estebank)

r? @estebank

Unfortunate but ok.

yea this one had me scratching my head. It's an unfortunate combination of opaque types and type inference, but has a good chance of getting properly resolved with cleanups that will be enabled by #113169

@bors r+

📌 Commit 965da3a has been approved by estebank

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

@bors r-

Finished benchmarking commit (870a01a): 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.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.2%, 1.0%]	14
Regressions ❌ (secondary)	1.2%	[0.1%, 3.5%]	23
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.2%, 1.0%]	14

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.

	mean	range	count
Regressions ❌ (primary)	8.6%	[2.5%, 14.8%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.0%	[-1.1%, -0.9%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.8%	[-1.1%, 14.8%]	4

Cycles

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.

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

Binary size

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

Bootstrap: 663.578s -> 662.662s (-0.14%)
Artifact size: 308.27 MiB -> 308.26 MiB (-0.00%)

@oli-obk: a bunch of possible icount regressions, is that expected?

I already opened a PR: #120771

it is not expected, but from the detailed diffs (only incremental cache changes, no actual execution changes), I presume it's that one missing ensure call

Weirdly, while that PR is a perf improvement, it's completely orthogonal to this PR (because I also fixed another missing ensure).

I'll dig into what happened here, This regression must be fixable, we're not actually doing extra work in successful builds, so it must just be some query/caching thing

The queries I'm ensureing here, are not decoded from the cache at all (they aren't cached). All that is happening is that they get checked for being green. Since only incr_comp_encode_dep_graph regresses, the issue is in fact writing the additional edge to the dep graph. I do not see a way to resolve this regression.

I mean, since we only use the query to check for errors at the individual item level, we could just not ensure the query if

• we know it must have already been invoked, and
• has_errors is false

but that feels quite hacky.

Perf regression fully resolved after #120835 (comment)

@rustbot label: +perf-regression-triaged