format_args
can create incorrect subspans for raw string literals that adopted another string literal’s span – assertion failed: bpos.to_u32() >= mbc.pos.to_u32() + mbc.bytes as u32
#114865
Labels
A-macros
Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)
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.
Playing around with
indoc
, I’ve noticed that while a format string thatindoc
doesn’t modify further, likeleads to an error message that has a span pointing into the string literal
When the string is modified by
indoc
(removing some leading whitespace) likethat leads to an error message spanning the whole string literal.
So far so good, this all looks intentional. However with raw string literals, the behavior is no longer the same:
Without modification
and with modification by
indoc
Now we have a span pointing to the wrong location.
Apparently that’s sufficient to make the compiler crash, if multi-byte characters are involved. E.g.
(run on rustexplorer.com)
This is the assertion that fails:
rust/compiler/rustc_span/src/lib.rs
Lines 1760 to 1762 in c57393e
As for a minimal reproduction, define a proc-macro
and then use it like so
Another fun effect: If the macro-generated string is longer, e.g.
then the error message first points in other places in my program, and eventually also into different files:
This reproduces for latest stable and nightly.
The text was updated successfully, but these errors were encountered: