-
Notifications
You must be signed in to change notification settings - Fork 13k
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
ICE in codemap::CodeMap::bytepos_to_file_charpos #24687
Comments
I was able to trace down the bug. It is due to me using a unicode character in the documentation of a function this somehow triggers the compiler bug. A minimal example is: src/main.rs
Cargo.toml
|
@brson @SimonSapin I believe Servo is also currently hitting this in the script crate during our current rust upgrade. |
Yes, at least the failing assertion is the same. Removing non-ASCII characters from doc comments didn’t seem to help, though. |
cc @pnkfelix might this be another overflow error? |
@Aatch recommended on IRC to build with
|
This is 4013523 lines / 299MB of output. |
my current hypothesis is that this addition in creader.rs is the problem; it is at the very least very suspicious considering that five lines up in the previous statement we are normalizing the position to zero by subtracting the |
(other good news: I have figured out how to make a regression test for this that will integrate into the rust test suite.) |
metdata: Fix zero-normalization of the pos of a `MultiByteChar` Fix #24687 The source byte/character mappings for every crate track the collection of multi-characters from its source files specially. When we import the source information for another file into the current compilation unit, we assign its byte-positions unique values by shifting them all by a fixed adjustment, tracked in the `start_pos` field. But when we pull out the source span information for one function from one crate and into our own crate, we need to re-normalize the byte positions: subtracting the old `start_pos` and adding the new `start_pos`. The `new_imported_filemap(..)` method handles adding the new `start_pos`, so all `creader` needs to do is re-normalize each `pos` to zero. It seems like it was indeed trying to do this, but it mistakenly added the old `start_pos` instead of subtracting it.
I’m getting an ICE when compiling https://github.com/nwin/gif/tree/cef32bb49589ff55135745b23ac54978ee6edecf using
cargo test
The text was updated successfully, but these errors were encountered: