diff options
| author | bors <bors@rust-lang.org> | 2015-04-29 10:40:03 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2015-04-29 10:40:03 +0000 |
| commit | 551a74dddd84cf01440ee84148ebd18bc68bd7c8 (patch) | |
| tree | da3b4e49858dd93844647dcaa60e7767e6c4ac99 /src/rustllvm/ExecutionEngineWrapper.cpp | |
| parent | 26c7635ccf12c66929d51a6d441c3a7672cddec4 (diff) | |
| parent | 2ae82fcd959db78debfb4cf5ef85d310da44f85c (diff) | |
| download | rust-551a74dddd84cf01440ee84148ebd18bc68bd7c8.tar.gz rust-551a74dddd84cf01440ee84148ebd18bc68bd7c8.zip | |
Auto merge of #24932 - pnkfelix:fix-issue-24687, r=huonw
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.
Diffstat (limited to 'src/rustllvm/ExecutionEngineWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
