-
Notifications
You must be signed in to change notification settings - Fork 0
leptos regression #173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Smells like #158 though. edit: possibly not. IDK. |
Edit: THIS IS ON CRATES.IO'S VERSION OF TACHYS, NOT THE FORK! Interestingly enough, there are more/different regressions when building tachys on nightly with the new solver:
|
Minimal-ish: //@ check-pass
//@ edition: 2018
//@ revisions: current next
//@[next] compile-flags: -Znext-solver
//@ ignore-compare-mode-next-solver (explicit revisions)
// Regression test for leptos when building it with the new solver. Unlike
// avoid-query-cycle-via-item-bound.rs we never actually use the auto trait bound
// of the opaque here, as that one is only necessary when trying to normalize the
// `<V as AttributeValue>::{synthetic#0}` RPITIT via the impl. Given the explicit
// `V: AttributeValue` where-bound, this associated item is rigid and we don't
// care whether the impl may apply.
use std::future::Future;
pub trait ReactiveFunction: Send {
type Output;
fn invoke(self) -> Self::Output;
}
trait AttributeValue {
fn resolve(self) -> impl Future<Output = ()> + Send;
}
impl<F, V> AttributeValue for F
where
F: ReactiveFunction<Output = V>,
V: AttributeValue,
{
async fn resolve(self) {
// this require `Self::Output: `
self.invoke().resolve().await
}
}
fn main() {} |
So, it seems that we're doing "unnecessary work" when normalizing the We could perhaps rework candidate assembly for |
…=compiler-errors do not unnecessarily leak auto traits in item bounds fixes rust-lang/trait-system-refactor-initiative#158 Not a fix for rust-lang/trait-system-refactor-initiative#173 as you may have realized/tried yourself, cc rust-lang#139788. However, fixing this feels desirable regardless and I don't see any reason not to. r? `@compiler-errors`
…=compiler-errors do not unnecessarily leak auto traits in item bounds fixes rust-lang/trait-system-refactor-initiative#158 Not a fix for rust-lang/trait-system-refactor-initiative#173 as you may have realized/tried yourself, cc rust-lang#139788. However, fixing this feels desirable regardless and I don't see any reason not to. r? ``@compiler-errors``
…=compiler-errors do not unnecessarily leak auto traits in item bounds fixes rust-lang/trait-system-refactor-initiative#158 Not a fix for rust-lang/trait-system-refactor-initiative#173 as you may have realized/tried yourself, cc rust-lang#139788. However, fixing this feels desirable regardless and I don't see any reason not to. r? ```@compiler-errors```
Rollup merge of rust-lang#139789 - lcnr:opaques-auto-trait-leakage, r=compiler-errors do not unnecessarily leak auto traits in item bounds fixes rust-lang/trait-system-refactor-initiative#158 Not a fix for rust-lang/trait-system-refactor-initiative#173 as you may have realized/tried yourself, cc rust-lang#139788. However, fixing this feels desirable regardless and I don't see any reason not to. r? ```@compiler-errors```
…-errors do not unnecessarily leak auto traits in item bounds fixes rust-lang/trait-system-refactor-initiative#158 Not a fix for rust-lang/trait-system-refactor-initiative#173 as you may have realized/tried yourself, cc #139788. However, fixing this feels desirable regardless and I don't see any reason not to. r? ```@compiler-errors```
Don't assemble non-env/bound candidates if projection is rigid Putting this up for an initial review, it's still missing comments, clean-up, and possibly a tweak to deal with ambiguities in the `BestObligation` folder. This PR fixes rust-lang/trait-system-refactor-initiative#173. Specifically, we're creating an unnecessary query cycle in normalization by assembling an *impl candidate* even if we know later on during `merge_candidates` that we'll be filtering out that impl candidate. This PR adjusts the `merge_candidates` to assemble *only* env/bound candidates if we have `TraitGoalProvenVia::ParamEnv | TraitGoalProvenVia::AliasBound`. I'll leave some thoughts/comments in the code. r? lcnr
edit: While this looks like a regression with tachys, turns out that leptos has its own fork of tachys: https://github.com/leptos-rs/leptos/tree/main/tachys
Not yet minimized.https://crater-reports.s3.amazonaws.com/pr-133502-1/try%23fa8e241660363f48d64b66b05eea58c93ab828fb/reg/leptos-0.7.8/log.txt
The text was updated successfully, but these errors were encountered: