-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Fix spans in LLVM-generated inline asm errors #110985
Conversation
r? @b-naber (rustbot has picked a reviewer for you, use r? to override) |
I'm having trouble making a test for this since git doesn't preserve CRLF line endings. |
@@ -1745,6 +1745,21 @@ impl SourceFile { | |||
BytePos::from_u32(pos.0 - self.start_pos.0 + diff) | |||
} | |||
|
|||
/// Calculates a normalized byte position from a byte offset relative to the | |||
/// start of the file. | |||
pub fn normalized_byte_pos(&self, offset: u32) -> BytePos { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really familiar with this code. I don't know what normalization in this context is, so I don't really understand what this function does. I also find it kind of surprising that functionality like this hasn't existed before and you need to implement it yourself to adjust some spans.
Feel free to assign to somebody else, if you don't have the time to explain what normalization is in this context (I don't have the time to read up on it unfortunately).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normalization refers to this function which removes the unicode BOM and converts \n\r
newlines to \r
when a new SourceFile
is added.
When we get an inline assembler error from LLVM during codegen, we import the expanded assembly code as a new SourceFile
, which can then be used for error reporting with spans. However the byte offsets given to us by LLVM are relative to the start of the original buffer, not the normalized one. Hence we need to convert those offsets to the normalized form when constructing spans.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, makes sense to me now. Can you maybe add the second part of your comment to the docs for that function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added the comment.
Previously, incorrect spans were reported if inline assembly contained CRLF (Windows) line endings. Fixes rust-lang#110885
07b33b6
to
bba2a1e
Compare
Thanks. @bors r+ rollup |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#110577 (Use fulfillment to check `Drop` impl compatibility) - rust-lang#110610 (Add Terminator conversion from MIR to SMIR, part #1) - rust-lang#110985 (Fix spans in LLVM-generated inline asm errors) - rust-lang#110989 (Make the BUG_REPORT_URL configurable by tools ) - rust-lang#111167 (debuginfo: split method declaration and definition) - rust-lang#111230 (add hint for =< as <=) - rust-lang#111279 (More robust debug assertions for `Instance::resolve` on built-in traits with non-standard trait items) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Previously, incorrect spans were reported if inline assembly contained CRLF (Windows) line endings.
Fixes #110885