-
Notifications
You must be signed in to change notification settings - Fork 13.4k
ICE in codemap::CodeMap::bytepos_to_file_charpos #24687
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: