Fix Deref args when #[const_trait] is enabled

[compiler-errors]

Fix Deref being a #[const_trait]. To fix this fully, we also need to pass the host param to method_autoderef_steps and make sure we use it correctly in Autoderef.

[compiler-errors]

@rustbot author

[bors]

☔ The latest upstream changes (presumably #118282) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

This code is still broken for two reasons:

1. method_autoderef_steps doesn't know anything about the constness of the function, so it fails to select a Deref impl cause of ambiguity
2. Projections have a host parameter but we don't currently know what to do with them...

[compiler-errors]

This is ready :>

We just need to pass the host param to Autoderef and canonicalize it in method_autoderef_steps.

@bors try @rust-timer queue

[bors]

⌛ Trying commit 38e0402 with merge 4a90a2c...

[bors]

☀️ Try build successful - checks-actions
Build commit: 4a90a2c (4a90a2c83dbb51ae7aa0f7efa5b3aba7cd165e4f)

[rust-timer]

Finished benchmarking commit (4a90a2c): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

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.1%, 0.7%]	38
Regressions ❌ (secondary)	0.5%	[0.2%, 0.8%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.1%, 0.7%]	38

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)	-	-	0
Regressions ❌ (secondary)	0.8%	[0.8%, 0.8%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.7%	[-2.7%, -2.7%]	1
All ❌✅ (primary)	-	-	0

Cycles

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

Binary size

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

Bootstrap: 673.958s -> 673.623s (-0.05%)
Artifact size: 312.41 MiB -> 312.44 MiB (0.01%)

[compiler-errors]

I feel like we just need to accept this perf regression 😅, since it's likely not possible to avoid needing to pass in the host param in method_autoderef_steps, and we're simply doing more work here. Happy to discuss this if anyone disagrees, though.

[fee1-dead]

sorry about the lack of response here, r=me after the two tiny nits

[compiler-errors]

I'm curious about perf...

@bors try @rust-timer queue

[bors]

⌛ Trying commit a453884 with merge 34aeaa2...

[bors]

☀️ Try build successful - checks-actions
Build commit: 34aeaa2 (34aeaa28971ceecb8ae34abcf0c3d6ab41e0a673)

[rust-timer]

Finished benchmarking commit (34aeaa2): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

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%, 0.7%]	40
Regressions ❌ (secondary)	0.4%	[0.2%, 0.8%]	11
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.2%, 0.7%]	40

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)	0.9%	[0.9%, 0.9%]	1
Regressions ❌ (secondary)	10.5%	[10.5%, 10.5%]	1
Improvements ✅ (primary)	-0.8%	[-1.1%, -0.5%]	2
Improvements ✅ (secondary)	-1.9%	[-2.5%, -1.3%]	3
All ❌✅ (primary)	-0.2%	[-1.1%, 0.9%]	3

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)	2.0%	[2.0%, 2.0%]	1
Improvements ✅ (primary)	-0.6%	[-0.8%, -0.5%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.6%	[-0.8%, -0.5%]	2

Binary size

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

Bootstrap: 667.831s -> 668.134s (0.05%)
Artifact size: 308.39 MiB -> 308.55 MiB (0.05%)

[fee1-dead]

I think there may be potential optimizations related to caching behavior with the host generic params. Currently the trait system would probably cache non-const trait bounds and const trait bounds separately. If we find a way to mark which host args come from the original obligation carried forward, then we'd only need to select traits once (considering that concrete impls like impl const always implements both non-const and const, giving us a happy path).

I'm not entirely sure why we'd have this many regressions, though. expected_host_effect_param_for_body is only different if we are in a const fn, where there shouldn't be any deref (though we'd still have to check when typechecking method calls?) We might try to fix the regressions on stable code by checking the effects feature somewhere, and just passing in tcx.consts.true_ if we don't have effects enabled.

[fee1-dead]

Well, hmm, it looks like expected_host_effect_param_for_body already forces the host the param to be true. Why would this have a regression then?

[compiler-errors]

I think it may just be due to additional caching. I will test a few things, but otherwise I feel like we should absorb the perf hit since it seems inevitable.

[fee1-dead]

feel free to r=me after you have done the testing

[compiler-errors]

This is gonna have to be reworked after @fee1-dead adjusts the const trait desugaring, I think. Or otherwise, this can be revived later.