metadata: Fix zero-normalization of the pos of a MultiByteChar#24932
Merged
bors merged 2 commits intorust-lang:masterfrom Apr 29, 2015
Merged
metadata: Fix zero-normalization of the pos of a MultiByteChar#24932bors merged 2 commits intorust-lang:masterfrom
MultiByteChar#24932bors merged 2 commits intorust-lang:masterfrom
Conversation
Contributor
|
r? @pcwalton (rust_highfive has picked a reviewer for you, use r? to override) |
Contributor
Author
|
(actually on reflection, even though the original problem case was using non-breaking space, it would probably be a good idea if I used a non-whitespace character in that regression test. let me adjust that.) Update: okay, that is fixed now. |
use visible characters for the multibyte character filler.
pnkfelix
force-pushed
the
fix-issue-24687
branch
from
84c2fd8 to
2ae82fc
Compare
Member
|
\o/ |
Contributor
|
@bors r+ |
Collaborator
|
📌 Commit 2ae82fc has been approved by |
Member
|
@bors: force The diagnostic one is running now, that's a rather small PR and can wait (probably ought to be rollup) |
Contributor
|
@bors p=1 |
Contributor
|
@bors force |
bors
added a commit
that referenced
this pull request
Apr 29, 2015
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.
Collaborator
Collaborator
Contributor
Author
|
triage: beta-nominated Considering that:
we probably should at least consider cherry-picking it to the beta channel. |
rust-highfive
added
the
beta-nominated
Contributor
|
For what it’s worth, cherry-picking does not affect Servo as we don’t use the beta or stable channel. |
Contributor
Author
|
@SimonSapin right, I just meant that if Servo was blocked by this, then it is reasonable to conclude that other clients, who we want to stay on beta/stable channels, will also be blocked by this. |
Contributor
|
Makes sense. |
Contributor
Author
|
Also, a quick followup note:
|
Merged
pnkfelix
added a commit
to pnkfelix/rust
that referenced
this pull request
Apr 29, 2015
Note it is safe, with respect to autobuilds, to land before rust-lang#24945. (In other words, landing this sooner won't break things for anyone any worse than they were already broken, since there are *other* tests that also add `-g` to their flags via `compile-flags: -g`.)
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this pull request
Apr 29, 2015
…24687-test Add `-g` (to testcase) that I should have included in PR rust-lang#24932. Note it is safe, with respect to autobuilds, to land before rust-lang#24945. (In other words, landing this sooner won't break things for anyone any worse than they were already broken, since there are *other* tests that also add `-g` to their flags via `compile-flags: -g`.)
Contributor
Author
|
accepted for backport to beta channel. (as a special case for 1.0; post 1.0 a change like this might need stronger motivation for backport...) |
pnkfelix
added
the
beta-accepted
brson
removed
the
beta-nominated
Contributor
|
Backported. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
metdata: Fix zero-normalization of the pos of a
MultiByteCharFix #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_posfield. 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 oldstart_posand adding the newstart_pos. Thenew_imported_filemap(..)method handles adding the newstart_pos, so allcreaderneeds to do is re-normalize eachposto zero.It seems like it was indeed trying to do this, but it mistakenly added the old
start_posinstead of subtracting it.