rust/tests/ui/traits/cache-reached-depth-ice.stderr

error: evaluate(Binder { value: TraitPredicate(<A as std::marker::Send>, polarity:Positive), bound_vars: [] }) = Ok(EvaluatedToOk)
  --> $DIR/cache-reached-depth-ice.rs:44:5
   |
LL | fn test<X: PointeeSized + Send>() {}
   |                           ---- predicate
...
LL |     test::<A>();
   |     ^^^^^^^^^

error: aborting due to 1 previous error
update tests 2023-06-19 15:39:55 +02:00			`error: evaluate(Binder { value: TraitPredicate(<A as std::marker::Send>, polarity:Positive), bound_vars: [] }) = Ok(EvaluatedToOk)`
tests: bless remaining tests These tests just need blessing, they don't have any interesting behaviour changes. Some of these tests have new errors because `LegacyReceiver` cannot be proven to be implemented now that it is also testing for `MetaSized` - but this is just a consequence of the other errors in the test. 2025-02-03 15:54:25 +00:00			`--> $DIR/cache-reached-depth-ice.rs:44:5`
have on_completion record subcycles Rework `on_completion` method so that it removes all provisional cache entries that are "below" a completed node (while leaving those entries that are not below the node). This corrects an imprecise result that could in turn lead to an incremental compilation failure. Under the old scheme, if you had: * A depends on... * B depends on A * C depends on... * D depends on C * T: 'static then the provisional results for A, B, C, and D would all be entangled. Thus, if A was `EvaluatedToOkModuloRegions` (because of that final condition), then the result for C and D would also be demoted to "ok modulo regions". In reality, though, the result for C depends only on C and itself, and is not dependent on regions. If we happen to evaluate the cycle starting from C, we would never reach A, and hence the result would be "ok". Under the new scheme, the provisional results for C and D are moved to the permanent cache immediately and are not affected by the result of A. 2021-05-11 05:40:42 -04:00			`\|`
tests: bless remaining tests These tests just need blessing, they don't have any interesting behaviour changes. Some of these tests have new errors because `LegacyReceiver` cannot be proven to be implemented now that it is also testing for `MetaSized` - but this is just a consequence of the other errors in the test. 2025-02-03 15:54:25 +00:00			`LL \| fn test<X: PointeeSized + Send>() {}`
			`\| ---- predicate`
have on_completion record subcycles Rework `on_completion` method so that it removes all provisional cache entries that are "below" a completed node (while leaving those entries that are not below the node). This corrects an imprecise result that could in turn lead to an incremental compilation failure. Under the old scheme, if you had: * A depends on... * B depends on A * C depends on... * D depends on C * T: 'static then the provisional results for A, B, C, and D would all be entangled. Thus, if A was `EvaluatedToOkModuloRegions` (because of that final condition), then the result for C and D would also be demoted to "ok modulo regions". In reality, though, the result for C depends only on C and itself, and is not dependent on regions. If we happen to evaluate the cycle starting from C, we would never reach A, and hence the result would be "ok". Under the new scheme, the provisional results for C and D are moved to the permanent cache immediately and are not affected by the result of A. 2021-05-11 05:40:42 -04:00			`...`
			`LL \| test::<A>();`
			`\| ^^^^^^^^^`

Show number in error message even for one error Co-authored-by: Adrian <adrian.iosdev@gmail.com> 2023-11-21 15:44:16 +00:00			`error: aborting due to 1 previous error`
have on_completion record subcycles Rework `on_completion` method so that it removes all provisional cache entries that are "below" a completed node (while leaving those entries that are not below the node). This corrects an imprecise result that could in turn lead to an incremental compilation failure. Under the old scheme, if you had: * A depends on... * B depends on A * C depends on... * D depends on C * T: 'static then the provisional results for A, B, C, and D would all be entangled. Thus, if A was `EvaluatedToOkModuloRegions` (because of that final condition), then the result for C and D would also be demoted to "ok modulo regions". In reality, though, the result for C depends only on C and itself, and is not dependent on regions. If we happen to evaluate the cycle starting from C, we would never reach A, and hence the result would be "ok". Under the new scheme, the provisional results for C and D are moved to the permanent cache immediately and are not affected by the result of A. 2021-05-11 05:40:42 -04:00