-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rustc "overflow evaluating the requirement" while it should work. #96634
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
This can be related: #39959, and consequently this as well: https://users.rust-lang.org/t/type-recursion-when-trait-bound-is-added-on-reference-type/74525 |
Why should our initial bound be considered true? Afaict what's going on here is that you have a cycle, once you hit your initial bound you try to again prove |
Such loops should be supported IMO, just as they are supported in Haskell, for example. If you have a bound |
Due to bug rust-lang/rust#96634, these generic bounds may cause an infinite recursion in the compiler, even in unrelated code. This specializes the `Write for &NamedTempFile<F>` impl on `File` instead. This keeps the API the same as before the generic parameter `F` was added, so it shouldn't break any code.
I ran into this issue today (Stebalien/tempfile#224) in the |
Due to bug rust-lang/rust#96634, these generic bounds may cause an infinite recursion in the compiler, even in unrelated code. This specializes the `Write for &NamedTempFile<F>` impl on `File` instead. This keeps the API the same as before the generic parameter `F` was added, so it shouldn't break any code.
Due to bug rust-lang/rust#96634, these generic bounds may cause an infinite recursion in the compiler, even in unrelated code. This specializes the `Write for &NamedTempFile<F>` impl on `File` instead. This keeps the API the same as before the generic parameter `F` was added, so it shouldn't break any code.
Any update on this issue? I am also getting this issue on GAT |
All cases of this error for me typically ended up being compiler failures to infer types. By removing code to localize where types can't be inferred and specifying types explicitly this error can be worked around. |
trait Handler: Send + Sync + 'static {}
#[derive(Hash, PartialEq, Eq, PartialOrd, Ord)]
struct SimpleChain<H: Send + Sync + 'static>
where &'static H: Handler
{
pub handler: H,
}
impl<H: Send + Sync + 'static> Handler for &'static SimpleChain<H>
where &'static H: Handler
{}
struct PruneChain;
impl Handler for &'static PruneChain {}
fn main() {
SimpleChain {
// SimpleChain::<PruneChain> {
handler: PruneChain,
};
} yields
but if the constructor is instead Given that this type is well-known ( |
Consider this code:
Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9014c0167fc65f14c8a2668428fc5df4
It gives the error:
Which does not make sense. Let me explain:
MyVisitor{}.visit(&Ast::Null)
, which requires a boundMyVisitor: Visit<Ast>
.impl<T> Visit<Ast> for T
), so another bound to be checked is added, which isMyVisitor: Visit<Box<Ast>>
.impl<T,S:?Sized> Visit<Box<S>> for T
), which while resolving (T
isMyVisitor
andS
isAst
) results in another bound to be resolved:MyVisitor: Visit<Ast>
. However, this is our initial bound that we are currently resolving so it should compile fine.A few things to be noted:
test
is commented out (only the usage throws the error (the impls are correct)).Box<Box<Box<...
situation should never happen in the Rustc type resolver - there is something wrong happening under the hood.The text was updated successfully, but these errors were encountered: