evaluation cache, freshen each predicate by itself

[lcnr]

I think this change is correct. Here's my understanding of this:

This previously wasn't done was so that we don't consider Foo<?0>: Trait requiring Foo<?0>: Trait (which is trivially a cycle), the same as Foo<?0>: Trait requiring Foo<?1>: Trait, which is an infinite chain instead.

For inductive obligations, cycles and infinite chains should both result in ambiguity, so for these this doesn't matter.

For coinductive obligations, cycles result in success and I believe that infinitely diverging chains should also be a success. That's my understanding given my limited experience with coq and the general intuition of "coinduction means stuff is true unless proven otherwise, induction means stuff is wrong unless proven otherwise".

r? @nikomatsakis cc @rust-lang/types

[lcnr]

keeping 'static here is wrong. I am changing this separately in #102472 which is blocked on #102635

[lcnr]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit da928700181422639a4c06f0ac832f3a87e65180 with merge 79e77056cd5cd1e6cd8cb883026e53a7f1ff0659...

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit da928700181422639a4c06f0ac832f3a87e65180 with merge f30cafb00d844ad0086efc9765084f4e994286f5...

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit da928700181422639a4c06f0ac832f3a87e65180 with merge 0cb6fd9f0ff8333a6cdc3b11e06197e42a2c8da5...

[bors]

☀️ Try build successful - checks-actions
Build commit: 0cb6fd9f0ff8333a6cdc3b11e06197e42a2c8da5 (0cb6fd9f0ff8333a6cdc3b11e06197e42a2c8da5)

[rust-timer]

Queued 0cb6fd9f0ff8333a6cdc3b11e06197e42a2c8da5 with parent 8c71b67, future comparison URL.

[rust-timer]

Finished benchmarking commit (0cb6fd9f0ff8333a6cdc3b11e06197e42a2c8da5): comparison URL.

Overall result: ❌✅ regressions and improvements - 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-review -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.

	mean1	range	count2
Regressions ❌ (primary)	0.8%	[0.8%, 0.8%]	1
Regressions ❌ (secondary)	1.1%	[1.1%, 1.1%]	1
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-0.3%	[-0.4%, -0.2%]	9
All ❌✅ (primary)	0.3%	[-0.2%, 0.8%]	2

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.

Footnotes

1. the arithmetic mean of the percent change↩

2. number of relevant changes↩

[lcnr]

@bors try

[nikomatsakis]

r=me but I think we should do a crater run

[bors]

⌛ Trying commit da928700181422639a4c06f0ac832f3a87e65180 with merge 7f168b18704203996d3698515c88a036a9300946...

[bors]

☀️ Try build successful - checks-actions
Build commit: 7f168b18704203996d3698515c88a036a9300946 (7f168b18704203996d3698515c88a036a9300946)

[lcnr]

@craterbot check

[craterbot]

👌 Experiment pr-102713 created and queued.
🤖 Automatically detected try build 7f168b18704203996d3698515c88a036a9300946
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-102713 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-102713 is completed!
📊 64 regressed and 6 fixed (244993 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[lcnr]

this changes some recursive paths from EvaluatedToUnknown to EvaluatedToRecur with EvaluatedToRecur getting treated differently, breaking existing crates.

Comparing the trait ref using structural eq, this previously failed as we had different fresh vars, now it succeeds:

rust/compiler/rustc_trait_selection/src/traits/select/mod.rs

Lines 846 to 853 in 1536ab1

	ifletSome(cycle_depth) = stack
	.iter()
	.skip(1)// Skip top-most frame.
	.find(|prev| {
	stack.obligation.param_env == prev.obligation.param_env
	&& stack.fresh_trait_pred == prev.fresh_trait_pred
	})
	.map(|stack| stack.depth)

This succeeds even for different fresh vars:

rust/compiler/rustc_trait_selection/src/traits/select/mod.rs

Lines 916 to 928 in 1536ab1

	if unbound_input_types
	&& stack.iter().skip(1).any(|prev| {
	stack.obligation.param_env == prev.obligation.param_env
	&& self.match_fresh_trait_refs(
	stack.fresh_trait_pred,
	prev.fresh_trait_pred,
	prev.obligation.param_env,
	)
	})
	{
	debug!("evaluate_stack --> unbound argument, recursive --> giving up",);
	returnOk(EvaluatedToUnknown);
	}

@jyn514 previously looked into changing EvaluatedToRecur. Reached out to him to figure out how to best make progress here.

[jyn514]

wip code here: https://github.com/jyn514/rust/pull/new/normalize-docs
but it doesn't work

[bors]

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

[lcnr]

when freshening each obligation by itself we have to correctly deal with inference constraints from the cyclic call. Otherwise we get the following issue:

traitFoo{}// assume `Foo` is coinductive herestructWrapper<T>(T);impl<T>FooforWrapper<Wrapper<T>>whereWrapper<T>:Foo{}

query: does Wrapper<?0>: Foo hold?

• candidate: impl<T> Foo for Wrapper<Wrapper<T>> -> ?0 -> Wrapper<?1>
  • nested: Wrapper<?1>: Foo COINDUCTIVE CYCLE OK
• query returns OK: ?0 = Wrapper<?1>

To deal with this evaluate has to return inference results which will only be added in the implementation of the trait system refactor initiative.