properly elaborate effects implied bounds for super traits

[fee1-dead]

Summary: This PR makes it so that we elaborate <T as Tr>::Fx: EffectsCompat<somebool> into <T as SuperTr>::Fx: EffectsCompat<somebool> when we know that trait Tr: ~const SuperTr.

Some discussion at rust-lang/project-const-traits#2.

r? project-const-traits
@rust-lang/project-const-traits: how do we feel about this approach?

[fee1-dead]

anyone from @rust-lang/project-const-traits willing to give a vibe check/review? ^^'

[compiler-errors]

I'm still trying to wrap my head around what's going on here. Perhaps some more comments and detailed explanation would help?

Sorry my life has been too chaotic to sit down and focus on what's going on here. I'll try to respond a bit more quickly moving forward.

[fee1-dead]

Perhaps some more comments and detailed explanation would help?

Yeah. I'll write more on this when I get time

@rustbot author

[compiler-errors]

Also, semi-related: I found a bug when looking at the (pre-existing) changes to push_trait_bound: #130666. See the second commit.

Specifically, we should only push an effects predicate for a trait if we're filtering to implied predicates, not super predicates.

[fee1-dead]

to do with performance

.. Hold on, let me just write stuff here because I'm going to sleep and too lazy right now to open up the code and tweak the comments. (also ping since you might have unsubscribed @compiler-errors)

There is a difference in what this does here vs. push_trait_bound that isn't just performance.

From a distant, high-level look, push_trait_bound implements the ~const modifier for a trait bound in terms of bounds on effects. It desugars to the normal non-const bound and adds requirements for the const context. This is placed there because push_trait_bound has access to HIR and we lose the information (in reality, encoded as a separate bound) whether a bound is ~const or not when we lower to MIR (in pre-effects, we used to attach those to the trait predicate and expected the trait solver to handle them: #114202)

what this PR does is it implements the propagation of ~const super trait implications. If I have trait Bar: ~const Foo and const fn foo<T: ~const Bar>(), I should expect to be able to use T as Foo in a const context as well. For non-const traits, the assumption T: Bar is elaborated to T: Foo in here as well. (during elaboration) We don't implement it in push_trait_bound the same reason we don't push T: Foo to const fn foo<T: Bar>().

[fee1-dead]

@rustbot ready

[compiler-errors]

@bors r+ rollup=never

[bors]

📌 Commit 7c2a24b has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

⌛ Testing commit 7c2a24b with merge 0e67c64...

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

💔 Test failed - checks-actions

[fee1-dead]

@bors retry spurious

[bors]

⌛ Testing commit 7c2a24b with merge 4e91ced...

[bors]

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 4e91ced to master...

[rust-timer]

Finished benchmarking commit (4e91ced): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.3%	[0.3%, 0.3%]	4
Regressions ❌ (secondary)	0.2%	[0.2%, 0.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.0%	[-2.0%, -2.0%]	1
All ❌✅ (primary)	0.3%	[0.3%, 0.3%]	4

Max RSS (memory usage)

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

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: 768.13s -> 768.577s (0.06%)
Artifact size: 341.39 MiB -> 341.42 MiB (0.01%)

[Kobzol]

The small regression looks genuine, but it's on nalgebra, which doesn't have its statistical threshold configured reasonably yet, since it has been in the suite for only a week.

@rustbot label: +perf-regression-triaged