ICE: attempted to subtract with overflow with No-Break Space and small terminal
#132918
Comments
matthiaskrgr
added
A-diagnostics
fmease
added
D-diagnostic-infra
|
I'm not able to replicate this issue. Do you have more information on how to replicate the overflow? |
|
did you build rustc with debug assertions? edit: may need rustc debug assertions as well as std debug assertions |
|
My Original PR (#134361) changes things to work as follows: Wide Terminal: Skinny Terminal: My question is, for a skinny terminal where is the The expected output posted previously has it to the left of the Indeed if I add 7 spaces before to the beginning of the file and repeat the the experiment with the wide and skinny terminal: Skinny: The same thing happens, but now offset 7 characters. If the |
|
Upon further investigation: I'm now fairly certain that The problem, I discovered is in the logic around what counts as leading white-space. The overflowing subtraction assumes that no errors will occur inside the leading whitespace. However it computes the length of that whitespace with std::char::is_whitespace and not rustc_lexer::is_whitespace. The former include no-break space and the later excludes it. We can only safely make the assumption that no errors occur in whitespace if it is all "Rust Standard" whitespace. Indeed an error does occur in unicode whitespace (if there is a no-break space). |
…avidtwco Fix logical error with what text is considered whitespace. There appears to be a logical issue around what counts as leading white-space. There is code which does a subtraction assuming that no errors will be reported inside the leading whitespace. However we compute the length of that whitespace with std::char::is_whitespace and not rustc_lexer::is_whitespace. The former will include a no-break space while later will excluded it. We can only safely make the assumption that no errors will be reported in whitespace if it is all "Rust Standard" whitespace. Indeed an error does occur in unicode whitespace if it contains a no-break space. In that case the subtraction will cause a ICE (for a compiler in debug mode) as described in rust-lang#132918.
…avidtwco Fix logical error with what text is considered whitespace. There appears to be a logical issue around what counts as leading white-space. There is code which does a subtraction assuming that no errors will be reported inside the leading whitespace. However we compute the length of that whitespace with std::char::is_whitespace and not rustc_lexer::is_whitespace. The former will include a no-break space while later will excluded it. We can only safely make the assumption that no errors will be reported in whitespace if it is all "Rust Standard" whitespace. Indeed an error does occur in unicode whitespace if it contains a no-break space. In that case the subtraction will cause a ICE (for a compiler in debug mode) as described in rust-lang#132918.
…avidtwco Fix logical error with what text is considered whitespace. There appears to be a logical issue around what counts as leading white-space. There is code which does a subtraction assuming that no errors will be reported inside the leading whitespace. However we compute the length of that whitespace with std::char::is_whitespace and not rustc_lexer::is_whitespace. The former will include a no-break space while later will excluded it. We can only safely make the assumption that no errors will be reported in whitespace if it is all "Rust Standard" whitespace. Indeed an error does occur in unicode whitespace if it contains a no-break space. In that case the subtraction will cause a ICE (for a compiler in debug mode) as described in rust-lang#132918.
Rollup merge of rust-lang#134366 - harrisonkaiser:no-break-space, r=davidtwco Fix logical error with what text is considered whitespace. There appears to be a logical issue around what counts as leading white-space. There is code which does a subtraction assuming that no errors will be reported inside the leading whitespace. However we compute the length of that whitespace with std::char::is_whitespace and not rustc_lexer::is_whitespace. The former will include a no-break space while later will excluded it. We can only safely make the assumption that no errors will be reported in whitespace if it is all "Rust Standard" whitespace. Indeed an error does occur in unicode whitespace if it contains a no-break space. In that case the subtraction will cause a ICE (for a compiler in debug mode) as described in rust-lang#132918.
|
Fixed in #134366 |
Fix logical error with what text is considered whitespace. There appears to be a logical issue around what counts as leading white-space. There is code which does a subtraction assuming that no errors will be reported inside the leading whitespace. However we compute the length of that whitespace with std::char::is_whitespace and not rustc_lexer::is_whitespace. The former will include a no-break space while later will excluded it. We can only safely make the assumption that no errors will be reported in whitespace if it is all "Rust Standard" whitespace. Indeed an error does occur in unicode whitespace if it contains a no-break space. In that case the subtraction will cause a ICE (for a compiler in debug mode) as described in rust-lang/rust#132918.
Code
This mix of spaces and "no-break-spaces" https://www.compart.com/en/unicode/U+00A0 seems to cause a problem with small terminals when the terminal is too small to show the entire code as diagnostic.
I guess rustc has problems while splitting the no-break-spaces?
Meta
rustc --version --verbose:de27914
Error output
output with sufficient screen space:
output when terminal is node wide enough ( may require std overflow checks )
Backtrace
The text was updated successfully, but these errors were encountered: