Skip to content
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

ICE: assertion failed: bpos.to_u32() >= mbc.pos.to_u32() + mbc.bytes as u32 #128845

Closed
matthiaskrgr opened this issue Aug 8, 2024 · 6 comments · Fixed by #128865
Closed

ICE: assertion failed: bpos.to_u32() >= mbc.pos.to_u32() + mbc.bytes as u32 #128845

matthiaskrgr opened this issue Aug 8, 2024 · 6 comments · Fixed by #128865
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. D-Unicode-unaware Diagnostics: Diagnostics that are unaware of Unicode and trigger codepoint boundary assertions I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@matthiaskrgr
Copy link
Member

auto-reduced (treereduce-rust):

fn main() {
    let RangeToInclusive: u8 ➖= 1; 
    
     
    
     
    let _ = c;
}

original:

fn main() {
    let RangeToInclusive: u8 ➖= 1; //~ ERROR can't reassign to an uninitialized variable
    let _ = A72;
    let b += 1; //~ ERROR can't reassign to an uninitialized variable
    let _ = test_elseif_panic;
    let c *= 1; //~ ERROR can't reassign to an uninitialized variable
    let _ = c;
}

Version information

rustc 1.82.0-nightly (2048386fe 2024-08-08)
binary: rustc
commit-hash: 2048386fe2898febe7315c0feb915458e41c7aa5
commit-date: 2024-08-08
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 19.1.0

Command:
/home/matthias/.rustup/toolchains/master/bin/rustc

Program output

error: unknown start of token: \u{2796}
 --> /tmp/icemaker_global_tempdir.Em76PNRIxxYR/rustc_testrunner_tmpdir_reporting.gVRjreTFFets/mvce.rs:2:30
  |
2 |     let RangeToInclusive: u8 ➖= 1; 
  |                              ^^
  |
help: Unicode character '➖' (Heavy Minus Sign) looks like '-' (Minus/Hyphen), but it is not
  |
2 |     let RangeToInclusive: u8 -= 1; 
  |                              ~

error: can't reassign to an uninitialized variable
 --> /tmp/icemaker_global_tempdir.Em76PNRIxxYR/rustc_testrunner_tmpdir_reporting.gVRjreTFFets/mvce.rs:2:30
  |
2 |     let RangeToInclusive: u8 ➖= 1; 
  |                              ^^^
  |
  = help: if you meant to overwrite, remove the `let` binding
thread 'rustc' panicked at compiler/rustc_span/src/lib.rs:2028:17:
assertion failed: bpos.to_u32() >= mbc.pos.to_u32() + mbc.bytes as u32
stack backtrace:
   0:     0x7e34f1ca3b0d - std::backtrace_rs::backtrace::libunwind::trace::h288a87c5e2679186
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/../../backtrace/src/backtrace/libunwind.rs:116:5
   1:     0x7e34f1ca3b0d - std::backtrace_rs::backtrace::trace_unsynchronized::h5284ad94e8c74688
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x7e34f1ca3b0d - std::sys::backtrace::_print_fmt::h371adc3f02dab1dd
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/sys/backtrace.rs:66:9
   3:     0x7e34f1ca3b0d - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h148e7d8e87bab30f
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/sys/backtrace.rs:39:26
   4:     0x7e34f1cf429b - core::fmt::rt::Argument::fmt::h7d54e75d5909de1b
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/core/src/fmt/rt.rs:173:76
   5:     0x7e34f1cf429b - core::fmt::write::hf6482455a45a91c7
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/core/src/fmt/mod.rs:1178:21
   6:     0x7e34f1c979a3 - std::io::Write::write_fmt::h78337f43013967dc
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/io/mod.rs:1823:15
   7:     0x7e34f1ca6302 - std::sys::backtrace::BacktraceLock::print::he76ad41bfebe12ae
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/sys/backtrace.rs:42:9
   8:     0x7e34f1ca6302 - std::panicking::default_hook::{{closure}}::hea2fb4697dfb5a9e
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/panicking.rs:266:22
   9:     0x7e34f1ca5f6e - std::panicking::default_hook::h1dd19741d2e30ca9
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/panicking.rs:293:9
  10:     0x7e34ee0ba397 - std[3ddd7f8965915055]::panicking::update_hook::<alloc[5625efa5c1f04643]::boxed::Box<rustc_driver_impl[a075302d1f094aad]::install_ice_hook::{closure#0}>>::{closure#0}
  11:     0x7e34f1ca6cf2 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h0b220dc3792e0071
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/alloc/src/boxed.rs:2164:9
  12:     0x7e34f1ca6cf2 - std::panicking::rust_panic_with_hook::h31e66c1e0f0e6e18
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/panicking.rs:805:13
  13:     0x7e34f1ca6973 - std::panicking::begin_panic_handler::{{closure}}::h1057116e4a630d6a
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/panicking.rs:664:13
  14:     0x7e34f1ca3ff9 - std::sys::backtrace::__rust_end_short_backtrace::h943392b86d4267f1
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/sys/backtrace.rs:170:18
  15:     0x7e34f1ca6634 - rust_begin_unwind
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/panicking.rs:662:5
  16:     0x7e34f1cf08f3 - core::panicking::panic_fmt::h8f072a14c223852d
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/core/src/panicking.rs:74:14
  17:     0x7e34f1cf097c - core::panicking::panic::h21e129948c7bcefa
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/core/src/panicking.rs:148:5
  18:     0x7e34ec62c220 - <rustc_span[d8ab92baa90519c6]::source_map::SourceMap>::lookup_char_pos
  19:     0x7e34f078653f - <rustc_span[d8ab92baa90519c6]::source_map::SourceMap>::is_valid_span
  20:     0x7e34f078b73f - <core[d8d378ef57b379bb]::iter::adapters::filter_map::FilterMap<core[d8d378ef57b379bb]::iter::adapters::cloned::Cloned<core[d8d378ef57b379bb]::iter::adapters::filter::Filter<core[d8d378ef57b379bb]::slice::iter::Iter<rustc_errors[859dc14a00acad37]::Substitution>, <rustc_errors[859dc14a00acad37]::CodeSuggestion>::splice_lines::{closure#0}>>, <rustc_errors[859dc14a00acad37]::CodeSuggestion>::splice_lines::{closure#1}> as core[d8d378ef57b379bb]::iter::traits::iterator::Iterator>::next
  21:     0x7e34f078eef2 - <rustc_errors[859dc14a00acad37]::emitter::HumanEmitter>::emit_messages_default
  22:     0x7e34f0805be7 - <rustc_errors[859dc14a00acad37]::emitter::HumanEmitter as rustc_errors[859dc14a00acad37]::emitter::Emitter>::emit_diagnostic
  23:     0x7e34f08071af - <rustc_errors[859dc14a00acad37]::DiagCtxtInner>::emit_diagnostic::{closure#3}
  24:     0x7e34f0804737 - rustc_interface[ecbe5e558f1e13b6]::callbacks::track_diagnostic::<core[d8d378ef57b379bb]::option::Option<rustc_span[d8ab92baa90519c6]::ErrorGuaranteed>>
  25:     0x7e34f0802bbe - <rustc_errors[859dc14a00acad37]::DiagCtxtInner>::emit_diagnostic
  26:     0x7e34f0802a6d - <rustc_errors[859dc14a00acad37]::DiagCtxtHandle>::emit_diagnostic
  27:     0x7e34f0801c15 - <rustc_span[d8ab92baa90519c6]::ErrorGuaranteed as rustc_errors[859dc14a00acad37]::diagnostic::EmissionGuarantee>::emit_producing_guarantee
  28:     0x7e34efa96900 - <rustc_parse[637f6a5d800c635f]::parser::Parser>::parse_local
  29:     0x7e34efa5ae6f - <rustc_parse[637f6a5d800c635f]::parser::Parser>::parse_stmt_without_recovery
  30:     0x7e34efa574c2 - <rustc_parse[637f6a5d800c635f]::parser::Parser>::parse_full_stmt
  31:     0x7e34efa54262 - <rustc_parse[637f6a5d800c635f]::parser::Parser>::parse_block_common
  32:     0x7e34eff5e33b - <rustc_parse[637f6a5d800c635f]::parser::Parser>::parse_fn
  33:     0x7e34eff625a1 - <rustc_parse[637f6a5d800c635f]::parser::Parser>::parse_item_kind
  34:     0x7e34eff5975a - <rustc_parse[637f6a5d800c635f]::parser::Parser>::parse_item_common
  35:     0x7e34eff5694f - <rustc_parse[637f6a5d800c635f]::parser::Parser>::parse_item_
  36:     0x7e34eff560ac - <rustc_parse[637f6a5d800c635f]::parser::Parser>::parse_mod
  37:     0x7e34f0614adf - <rustc_interface[ecbe5e558f1e13b6]::queries::Queries>::parse
  38:     0x7e34f045ce21 - rustc_interface[ecbe5e558f1e13b6]::interface::run_compiler::<core[d8d378ef57b379bb]::result::Result<(), rustc_span[d8ab92baa90519c6]::ErrorGuaranteed>, rustc_driver_impl[a075302d1f094aad]::run_compiler::{closure#0}>::{closure#1}
  39:     0x7e34f036a489 - std[3ddd7f8965915055]::sys::backtrace::__rust_begin_short_backtrace::<rustc_interface[ecbe5e558f1e13b6]::util::run_in_thread_with_globals<rustc_interface[ecbe5e558f1e13b6]::util::run_in_thread_pool_with_globals<rustc_interface[ecbe5e558f1e13b6]::interface::run_compiler<core[d8d378ef57b379bb]::result::Result<(), rustc_span[d8ab92baa90519c6]::ErrorGuaranteed>, rustc_driver_impl[a075302d1f094aad]::run_compiler::{closure#0}>::{closure#1}, core[d8d378ef57b379bb]::result::Result<(), rustc_span[d8ab92baa90519c6]::ErrorGuaranteed>>::{closure#0}, core[d8d378ef57b379bb]::result::Result<(), rustc_span[d8ab92baa90519c6]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[d8d378ef57b379bb]::result::Result<(), rustc_span[d8ab92baa90519c6]::ErrorGuaranteed>>
  40:     0x7e34f036a232 - <<std[3ddd7f8965915055]::thread::Builder>::spawn_unchecked_<rustc_interface[ecbe5e558f1e13b6]::util::run_in_thread_with_globals<rustc_interface[ecbe5e558f1e13b6]::util::run_in_thread_pool_with_globals<rustc_interface[ecbe5e558f1e13b6]::interface::run_compiler<core[d8d378ef57b379bb]::result::Result<(), rustc_span[d8ab92baa90519c6]::ErrorGuaranteed>, rustc_driver_impl[a075302d1f094aad]::run_compiler::{closure#0}>::{closure#1}, core[d8d378ef57b379bb]::result::Result<(), rustc_span[d8ab92baa90519c6]::ErrorGuaranteed>>::{closure#0}, core[d8d378ef57b379bb]::result::Result<(), rustc_span[d8ab92baa90519c6]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[d8d378ef57b379bb]::result::Result<(), rustc_span[d8ab92baa90519c6]::ErrorGuaranteed>>::{closure#1} as core[d8d378ef57b379bb]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
  41:     0x7e34f1cb0a0b - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h8531124d63bf03d4
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/alloc/src/boxed.rs:2150:9
  42:     0x7e34f1cb0a0b - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h14280c2e7cc937ab
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/alloc/src/boxed.rs:2150:9
  43:     0x7e34f1cb0a0b - std::sys::pal::unix::thread::Thread::new::thread_start::hfbbba69bca48c3db
                               at /rustc/2048386fe2898febe7315c0feb915458e41c7aa5/library/std/src/sys/pal/unix/thread.rs:110:17
  44:     0x7e34f1a3cded - <unknown>
  45:     0x7e34f1ac00dc - <unknown>
  46:                0x0 - <unknown>

error: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: please make sure that you have updated to the latest nightly

note: rustc 1.82.0-nightly (2048386fe 2024-08-08) running on x86_64-unknown-linux-gnu

query stack during panic:
end of query stack
error: aborting due to 2 previous errors


@matthiaskrgr matthiaskrgr added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Aug 8, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Aug 8, 2024
@workingjubilee
Copy link
Member

@matthiaskrgr Can you start pingbacking #128790 at least for all of these?

@matthiaskrgr
Copy link
Member Author

ice since #127407

@matthiaskrgr
Copy link
Member Author

@workingjubilee can you add a filter for is:issue is:open label:I-ICE "bpos.to_u32" into the ticket you mentioned? That should find all relevant past an future issues automatically I think.

@workingjubilee
Copy link
Member

@matthiaskrgr A filter? How do I do that?

@workingjubilee
Copy link
Member

oh, you mean a link

@jieyouxu jieyouxu added A-diagnostics Area: Messages for errors, warnings, and lints D-Unicode-unaware Diagnostics: Diagnostics that are unaware of Unicode and trigger codepoint boundary assertions and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Aug 9, 2024
@jieyouxu
Copy link
Member

jieyouxu commented Aug 9, 2024

@workingjubilee can you add a filter for is:issue is:open label:I-ICE "bpos.to_u32" into the ticket you mentioned? That should find all relevant past an future issues automatically I think.

I added a label D-diagnostic-unaware, I'll go back and tag some of them later.

@jieyouxu jieyouxu self-assigned this Aug 9, 2024
rust-cloud-vms bot pushed a commit to jieyouxu/rust that referenced this issue Aug 9, 2024
For codepoint boundary assertion triggered by a let stmt compound
assignment removal suggestion when encountering recovered multi-byte
compound ops.

Issue: <rust-lang#128845>
rust-cloud-vms bot pushed a commit to jieyouxu/rust that referenced this issue Aug 9, 2024
…t codepoint boundaries

Previously we would try to issue a suggestion for `let x <op>= 1`, i.e.
a compound assignment within a `let` binding, to remove the `<op>`. The
suggestion code unfortunately incorrectly assumed that the `<op>` is an
exactly-1-byte ASCII character, but this assumption is incorrect because
we also recover Unicode-confusables like `➖=` as `-=`. In this example,
the suggestion code used a `+ BytePos(1)` to calculate the span of the
`<op>` codepoint that looks like `-` but the mult-byte Unicode
look-alike would cause the suggested removal span to be inside a
multi-byte codepoint boundary, triggering a codepoint boundary
assertion.

Issue: <rust-lang#128845>
rust-cloud-vms bot pushed a commit to jieyouxu/rust that referenced this issue Aug 9, 2024
…t codepoint boundaries

Previously we would try to issue a suggestion for `let x <op>= 1`, i.e.
a compound assignment within a `let` binding, to remove the `<op>`. The
suggestion code unfortunately incorrectly assumed that the `<op>` is an
exactly-1-byte ASCII character, but this assumption is incorrect because
we also recover Unicode-confusables like `➖=` as `-=`. In this example,
the suggestion code used a `+ BytePos(1)` to calculate the span of the
`<op>` codepoint that looks like `-` but the mult-byte Unicode
look-alike would cause the suggested removal span to be inside a
multi-byte codepoint boundary, triggering a codepoint boundary
assertion.

Issue: <rust-lang#128845>
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 9, 2024
Ensure let stmt compound assignment removal suggestion respect codepoint boundaries

Previously we would try to issue a suggestion for `let x <op>= 1`, i.e.
a compound assignment within a `let` binding, to remove the `<op>`. The
suggestion code unfortunately incorrectly assumed that the `<op>` is an
exactly-1-byte ASCII character, but this assumption is incorrect because
we also recover Unicode-confusables like `➖=` as `-=`. In this example,
the suggestion code used a `+ BytePos(1)` to calculate the span of the
`<op>` codepoint that looks like `-` but the mult-byte Unicode
look-alike would cause the suggested removal span to be inside a
multi-byte codepoint boundary, triggering a codepoint boundary
assertion.

The fix is to use `SourceMap::start_point(token_span)` which properly accounts for codepoint boundaries.

Fixes rust-lang#128845.

cc rust-lang#128790

r? `@fmease`
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 9, 2024
Ensure let stmt compound assignment removal suggestion respect codepoint boundaries

Previously we would try to issue a suggestion for `let x <op>= 1`, i.e.
a compound assignment within a `let` binding, to remove the `<op>`. The
suggestion code unfortunately incorrectly assumed that the `<op>` is an
exactly-1-byte ASCII character, but this assumption is incorrect because
we also recover Unicode-confusables like `➖=` as `-=`. In this example,
the suggestion code used a `+ BytePos(1)` to calculate the span of the
`<op>` codepoint that looks like `-` but the mult-byte Unicode
look-alike would cause the suggested removal span to be inside a
multi-byte codepoint boundary, triggering a codepoint boundary
assertion.

The fix is to use `SourceMap::start_point(token_span)` which properly accounts for codepoint boundaries.

Fixes rust-lang#128845.

cc rust-lang#128790

r? ``@fmease``
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Aug 9, 2024
Ensure let stmt compound assignment removal suggestion respect codepoint boundaries

Previously we would try to issue a suggestion for `let x <op>= 1`, i.e.
a compound assignment within a `let` binding, to remove the `<op>`. The
suggestion code unfortunately incorrectly assumed that the `<op>` is an
exactly-1-byte ASCII character, but this assumption is incorrect because
we also recover Unicode-confusables like `➖=` as `-=`. In this example,
the suggestion code used a `+ BytePos(1)` to calculate the span of the
`<op>` codepoint that looks like `-` but the mult-byte Unicode
look-alike would cause the suggested removal span to be inside a
multi-byte codepoint boundary, triggering a codepoint boundary
assertion.

The fix is to use `SourceMap::start_point(token_span)` which properly accounts for codepoint boundaries.

Fixes rust-lang#128845.

cc rust-lang#128790

r? ```@fmease```
@bors bors closed this as completed in 665a1a4 Aug 9, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Aug 9, 2024
Rollup merge of rust-lang#128865 - jieyouxu:unicurd, r=Urgau

Ensure let stmt compound assignment removal suggestion respect codepoint boundaries

Previously we would try to issue a suggestion for `let x <op>= 1`, i.e.
a compound assignment within a `let` binding, to remove the `<op>`. The
suggestion code unfortunately incorrectly assumed that the `<op>` is an
exactly-1-byte ASCII character, but this assumption is incorrect because
we also recover Unicode-confusables like `➖=` as `-=`. In this example,
the suggestion code used a `+ BytePos(1)` to calculate the span of the
`<op>` codepoint that looks like `-` but the mult-byte Unicode
look-alike would cause the suggested removal span to be inside a
multi-byte codepoint boundary, triggering a codepoint boundary
assertion.

The fix is to use `SourceMap::start_point(token_span)` which properly accounts for codepoint boundaries.

Fixes rust-lang#128845.

cc rust-lang#128790

r? ````@fmease````
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. D-Unicode-unaware Diagnostics: Diagnostics that are unaware of Unicode and trigger codepoint boundary assertions I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants