-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
error[E0275]: overflow evaluating the requirement _: std::marker::Sized
#39959
Comments
Sadly, due to rust-lang/rust#39959, we can't make take the mapper by reference
* Add non-consuming Coproduct fold, HList map and foldLeft * Missing HList foldRight because of rust-lang/rust#39959
I've also hit this bug (is it fair to say it is a bug?) I was able to condense my error condition down to // the writing is on the wall, let's not look at the entire wall
#![recursion_limit="10"]
struct Encoder {}
trait CanEncode { fn write(self); }
impl Encoder {
fn write<E: CanEncode>(&mut self, x: E) { x.write() }
}
impl<'a, T> CanEncode for &'a [T] where
&'a T: CanEncode
{
fn write(self) {}
}
fn main() {
let mut wtr = Encoder {};
wtr.write::<&[_]>(42).unwrap();
} this gives the curious and (to me) nonsensical error message:
It's not very clear what's going on here. I have absolutely no idea why the compiler is checking &[[[_]]] and so forth, and I have absolutely no idea why it's checking Sized for these, and why it can't figure out it's never going to work. All in all, it's really confusing, and it smells a lot like a bug, to me. |
Is there any way to fix this, and if not, will it be fixed when chalk lands? |
The plot thickens... use std::io::{Read, Write};
use std::fs::File;
use std::path::Path;
// Comment this out... and everything will work fine
use thisdoesntexistyolo::haha;
struct Something<T: Read + Write> {
thing: T,
}
impl<'a, T: 'a + Read + Write> Something<T>
where &'a T: Read
{
fn new(thing: T) -> Something<T> {
Something { thing }
}
}
fn main() {
let file = File::open(Path::new("doesntmatter.txt")).unwrap();
let mut st: Something<File> = Something::new(file);
}
|
Minimized test case from #39959 (comment) (also changed to trait Trait {}
impl<'a, T> Trait for &'a Vec<T> where &'a T: Trait {}
fn call<E: Trait>() {}
fn foo() {
call::<&Vec<_>>();
} Reproducible on every stable Rust back to 1.0, beta and nightly. Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7ffb08380a25020785bf958a3e600687. |
Same error with a struct instead of struct Struct<T> where T: Sized {
t: T
}
trait Trait {}
impl<'a, T> Trait for &'a Struct<T> where &'a T: Trait {}
fn call<E: Trait>() {}
fn foo() {
call::<&Struct<_>>();
} |
We can't read from the original file, because we want to be able to use that as the writer in `apply()`. Previously, this would result in the original file simply being truncated, as we weren't reading from the correct file. To fix this, we need to give `apply_to()` both a reader and a writer. Now, in `apply()`, we can pass it the temporary file to read, and the original to write to. Used a `Path` as an input to `apply_to()` instead of a `Read`er because I got an error that didn't really make sense to me when I did so: error[E0275]: overflow evaluating the requirement `&tokio_reactor::poll_evented::PollEvented<_>: std::io::Read` | = help: consider adding a `#![recursion_limit="256"]` attribute to your crate (`git_suggested_patch`) = note: required because of the requirements on the impl of `std::io::Read` for `&tokio_reactor::poll_evented::PollEvented<tokio_reactor::poll_evented::PollEvented<_>>` = note: required because of the requirements on the impl of `std::io::Read` for `&tokio_reactor::poll_evented::PollEvented<tokio_reactor::poll_evented::PollEvented<tokio_reactor::poll_evented::PollEvented<_>>>` A search for the error message turned up a few active issues: - rust-lang/rust#57854 - rust-lang/rust#62755 - rust-lang/rust#39959 The above issues indicate that this could come from having a variable with an inferred type. However, for the moment the issue isn't resolved, and the error message doesn't indicate where the problem is actually coming from. As I was unable to track down the source of the problem, I decided not to bother using a `Read` argument.
I think I've found an even nastier reproduction of this. Not only do I get the same (long) error output, but mine didn't even reference a file, or a line… Just the error message, number, and the recursion. That is,
In my example, there is an error in the code: Stable, 1.48.0, and nightly 2020-12-03, though nightly is kind enough to elide some of the redundant impls. (But still fails to identify a line/file.) |
Triage: almost no change. The requirements list now hides the intermediary steps if they repeat, so at least now the output is less verbose. The last case still doesn't have a span. |
I'm writing a numerical crate and am encountering this bug a lot. So far, I've been able to get around it by cloning my values which reduces the complexity of my trait constraints but I can never tell what triggers the bug. Here's a minimal example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=88f2fbd8464ede697605101f29dbcda0 |
Another instance of this showed up on URLO with a playground link that produces the error. I was able to find a workaround for this case by adding a bound type variable. I have reproduced the differing sections below. Compile Error:
Compiles Successfully:
|
Here's another tiny test-case by @lemmih that we ran into when using the ordered_float crate: reem/rust-ordered-float#91 (comment) |
Triage: Current output for original report:
For the third report:
For the second report:
Fifth report:
The case that loses spans now looks like this, still without a span:
The other example linked:
And the output for the last two comments, which are using recent compilers so their output hasn't changed:
|
Further progress on this application is blocked by rust-lang/rust#39959
Another case here on URLO |
There are multiple bugs here and the most minimal example does not show the worst bug. struct Struct<T>(T);
trait Trait {}
impl<T> Trait for Struct<T> where T: Trait {}
impl Trait for u8 {}
fn call<E: Trait>() {}
fn foo() {
call::<Struct<_>>();
} The above code must fail with "type annotations needed" because both But the actually bad bug, which I'm fairly sure exists is that code that should compile does not. @e2-71828 posted an example of that but that one compiles in the current playground. I'm pretty sure that I've encountered it recently but unfortunately I didn't save the problematic version of the code anywhere. If you find this issue while debugging that, please post the code. |
I was interested where that issue got fixed (I originally authored that example) so I spent some time bisecting the fix today. bors 4a99c5f is the first commit that builds my example successfully, which is an auto-merge of #97345 |
The nature of the speedup from that PR is seemingly some kind of early pruning inside the trait solver. It’s possible that the logic used there consistently prunes away the problematic branches before they get a chance to infinitely recurse. |
Hello, I have another repro to add to the pile. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=3d0813888dd49475147c9cfbed636797 Looks like it's okay if the trait recurses immediately (taking an |
I have figured out the root cause! evaluate_stack has code that is supposed to prevent exactly this case. But there is a bug in I am not yet sure what the fix is because while this is incorrect for |
The original case now ICEs :( |
Doesn't look like it ICEs with the latest nightly (2023-07-13) |
|
I don't see an ICE either any longer @rustbot label -I-ICE |
The test case in the description doesn't seem to overflow with
|
I have created an interesting problem the compiler cannot resolve a type. I do not know if this is a compiler issue or if I am simply doing something wrong, but the diagnostic information I am given does not really help me understand what the issue. Before I updated my toolchain, it gave me no errors, and in my production code I can actually get the compiler to go into an infinite loop that never completes, but I'm not able to reproduce that. The below code will work if I simply remove the trait hints on the trait type
|
Interesting that we are having this problem but only on subsequent compiles. If we clear the target directory it compiles without fail... make one change and we get the overflow error. Our code example is rather complex with async-graphql wrapping deeply nested objects, but we combed through them ensuring they aren't self referential causing recursion. |
I have run into error[E0275] as well. If I have: pub fn foo(it: impl Iterator<Item = i32>, x: i32) {
if x >= 10 {
return;
} else {
let it_next = it.map(|x| x + 1);
foo(it_next, x + 1);
}
} I'm not sure if this should compile, because it looks like we are creating a infinite type here, but it does compile. However, as soon as I make it instantiate for another iterator type: pub fn main() {
foo([1, 2, 3].into_iter(), 0);
} It throws the said error:
Edit: that was on 1.77.2, on 1.82 it now shows this:
Still, without calling it the function compiles, which I find confusing. |
Reduced test case:
Output in rustc 1.17.0-nightly (536a900 2017-02-17):
Without
#![recursion_limit = "5"]
, the error message is similar but much larger. If this isn’t a bug, at least the diagnostic should be improved.The text was updated successfully, but these errors were encountered: