Skip to content

Reject non-char-boundary ranges in Literal::subspan - #156302

Open
el-ev wants to merge 1 commit into
rust-lang:mainfrom
el-ev:issue156049
Open

Reject non-char-boundary ranges in Literal::subspan#156302
el-ev wants to merge 1 commit into
rust-lang:mainfrom
el-ev:issue156049

Conversation

@el-ev

@el-ev el-ev commented May 8, 2026

Copy link
Copy Markdown
Contributor

Resolves #156049.

Prevent creation of subspans whose start or end falls inside a UTF-8 character in the source.

Before:

thread 'rustc' (2546552) panicked at compiler/rustc_span/src/source_map.rs:914:26:
start byte index 382 is not a char boundary; it is inside '🦀' (bytes 381..385 of string)

After: (doesn't ICE)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 8, 2026
@rustbot

rustbot commented May 8, 2026

Copy link
Copy Markdown
Collaborator

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 73 candidates
  • Random selection from 19 candidates

let TokenTree::Literal(lit) = input.into_iter().next().unwrap() else {
panic!("expected a string literal");
};
let bad = lit.subspan(2..3).expect("subspan");

@bjorn3 bjorn3 May 8, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does the .subspan() not return an error when it isn't on a character boundary? A span which doesn't start and end at a character boundary is nonsensical IMHO. Returning an error here would mean that code dealing with spans never has to deal with such malformed spans. I'm pretty sure start_point is not the only method that crashes when a span doesn't start and end at a character boundary.

View changes since the review

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me look into that.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed on the proc_macro side. Reverted the previous change since it wasn't a targeted fix.

@el-ev el-ev changed the title Fix ICE in SourceMap::start_point with non-char-boundary spans Reject non-char-boundary ranges in Literal::subspan May 8, 2026
@el-ev
el-ev requested a review from bjorn3 May 8, 2026 13:13
@el-ev

el-ev commented May 26, 2026

Copy link
Copy Markdown
Contributor Author

Ping.

Comment on lines +801 to +802
Ok(src.is_char_boundary(span_start + start)
&& src.is_char_boundary(span_start + end))

@bjorn3 bjorn3 Jun 11, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this is a bit nicer?

Suggested change
Ok(src.is_char_boundary(span_start + start)
&& src.is_char_boundary(span_start + end))
Ok(src.get(span_start + start..span_start + end).is_some())

View changes since the review

Ok(src.is_char_boundary(span_start + start)
&& src.is_char_boundary(span_start + end))
})
.unwrap_or(true);

@bjorn3 bjorn3 Jun 11, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can result in invalid spans getting embedded in the crate metadata if the source is not available while compiling the current crate, and if the source is then available when compiling a dependent crate that could result in a crash again. The SourceFile contains the locations of multi byte characters in the multibyte_chars field even if the source is unavailable, but there doesn't seem to be any api exposed to use this for span offset validation.

View changes since the review

@Enselic Enselic added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ICE on spans with unicode characters

5 participants