-
Notifications
You must be signed in to change notification settings - Fork 13.3k
'rustc' panicked at 'called Result::unwrap()
on an Err
value: TryFromIntError(())
#112934
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
Result::unwrap()
on an Err
value: TryFromIntError(())Result::unwrap()
on an Err
value: TryFromIntError(())
The problem is that rustc encodes a lot of metadata into tables with Splitting your project into multiple crates might help you dodge this issue until it is fixed. |
Splitting the project into multiple crates fixed the issue but it is from from ideal. Is this an easy and quick fix or does this require extensive knowledge about the compiler? I may consider attempting it if not even though I have no idea where to start. Also, in the event I am unsuccessful, would you happen to know average turn around times for issues like this? Thanks again! |
I expect that fixing this will be somewhat challenging. Upgrading any one code path to use a larger index is not that difficult but there are many. And it will probably impose a slowdown on all compiles, which is tough to swallow. If you want to try to tackle this, the Rust Zulip has a t-compiler/help stream where a number of people could pitch in and help you through trying to fix this. https://forge.rust-lang.org/platforms/zulip.html This is not a regression so it will not be automatically prioritized but I will nominate the general topic of using 32-bit indices for discussion at the next compiler team weekly meeting. Running out of 32-bit indices like this is quite rare but I have seen it before. |
@saethlin could we, as a stop gap, avoid the ICE and produce a hard error asking the user to split their project into multiple crates? There are already errors for recursion limits in Rust and other languages, so it would seem reasonable to have a better DX for an implementation limitation. I could also see us using a new-type index that could be |
Adding a hard error for this code path sounds like a worthy experiment. It's not clear to me if adding a compiler flag to toggle the index size would be any better than just switching to |
T-compiler discussed during triage meeting on Zulip (notes). We agree on the suggestion to turn the ICE into an error and to explore the idea of increasing the index size to @rustbot label -I-compiler-nominated |
I'm seeing this on nightly when building a crate with multiple (64) large (30-80MB) |
The real solution to your trouble is for my PR linked above to be merged, but FWIW it seems very unlikely to me that my changes to improve If you want to know which PR caused the change you should use https://github.com/rust-lang/cargo-bisect-rustc (just make sure to install from git, the published version is broken). |
Adapt table sizes to the contents This is an implementation of rust-lang/compiler-team#666 The objective of this PR is to permit the rmeta format to accommodate larger crates that need offsets larger than a `u32` can store without compromising performance for crates that do not need such range. The second commit is a number of tiny optimization opportunities I noticed while looking at perf recordings of the first commit. The rmeta tables need to have fixed-size elements to permit lazy random access. But the size only needs to be fixed _per table_, not per element type. This PR adds another `usize` to the table header which indicates the table element size. As each element of a table is set, we keep track of the widest encoded table value, then don't bother encoding all the unused trailing bytes on each value. When decoding table elements, we copy them to a full-width array if they are not already full-width. `LazyArray` needs some special treatment. Most other values that are encoded in tables are indexes or offsets, and those tend to be small so we get to drop a lot of zero bytes off the end. But `LazyArray` encodes _two_ small values in a fixed-width table element: A position of the table and the length of the table. The treatment described above could trim zero bytes off the table length, but any nonzero length shields the position bytes from the optimization. To improve this, we interleave the bytes of position and length. This change is responsible for about half of the crate metadata win on many crates. Fixes rust-lang/rust#112934 (probably) Fixes rust-lang/rust#103607
Adapt table sizes to the contents This is an implementation of rust-lang/compiler-team#666 The objective of this PR is to permit the rmeta format to accommodate larger crates that need offsets larger than a `u32` can store without compromising performance for crates that do not need such range. The second commit is a number of tiny optimization opportunities I noticed while looking at perf recordings of the first commit. The rmeta tables need to have fixed-size elements to permit lazy random access. But the size only needs to be fixed _per table_, not per element type. This PR adds another `usize` to the table header which indicates the table element size. As each element of a table is set, we keep track of the widest encoded table value, then don't bother encoding all the unused trailing bytes on each value. When decoding table elements, we copy them to a full-width array if they are not already full-width. `LazyArray` needs some special treatment. Most other values that are encoded in tables are indexes or offsets, and those tend to be small so we get to drop a lot of zero bytes off the end. But `LazyArray` encodes _two_ small values in a fixed-width table element: A position of the table and the length of the table. The treatment described above could trim zero bytes off the table length, but any nonzero length shields the position bytes from the optimization. To improve this, we interleave the bytes of position and length. This change is responsible for about half of the crate metadata win on many crates. Fixes rust-lang/rust#112934 (probably) Fixes rust-lang/rust#103607
Adapt table sizes to the contents This is an implementation of rust-lang/compiler-team#666 The objective of this PR is to permit the rmeta format to accommodate larger crates that need offsets larger than a `u32` can store without compromising performance for crates that do not need such range. The second commit is a number of tiny optimization opportunities I noticed while looking at perf recordings of the first commit. The rmeta tables need to have fixed-size elements to permit lazy random access. But the size only needs to be fixed _per table_, not per element type. This PR adds another `usize` to the table header which indicates the table element size. As each element of a table is set, we keep track of the widest encoded table value, then don't bother encoding all the unused trailing bytes on each value. When decoding table elements, we copy them to a full-width array if they are not already full-width. `LazyArray` needs some special treatment. Most other values that are encoded in tables are indexes or offsets, and those tend to be small so we get to drop a lot of zero bytes off the end. But `LazyArray` encodes _two_ small values in a fixed-width table element: A position of the table and the length of the table. The treatment described above could trim zero bytes off the table length, but any nonzero length shields the position bytes from the optimization. To improve this, we interleave the bytes of position and length. This change is responsible for about half of the crate metadata win on many crates. Fixes rust-lang/rust#112934 (probably) Fixes rust-lang/rust#103607
I am having compiler errors when compiling my project and there is no specific code that causes the issue. The issue goes away when the size of the file decreases. The file is very long (~85 000 lines) and it is generated by a script. When the first half of the file is removed, it compiles, when the last half is removed it also compiles. But when both are present it does not compile which leads me to believe it is an issue with the length of the file or the number of repeated structs/enums. I have included a code example of a minimum reproducible example. The functions in the file are all similar in structure except with different struct and enum names and extra conditional branches depending on the attributes present in the structs. They represent resolvers in my GraphQL API for the
async-graphql
lib.I also have 96GB of ram in my machine.
The issue still persists when the
--jobs
is set to 1 and whencargo clean
if run before compile. Also persists when compiling in--release
modeCode
Meta
rustc --version --verbose
:Error also persists on nightly (1.72) and in both debug and release mode for compilation in all versions and also in 1.69.
Error output
Backtrace
The text was updated successfully, but these errors were encountered: