Sitelet https://github.com/starkware-libs/cairo/pull/10017
Skip to content

fix(semantic): use exclusive upper bound in ExpansionOffset::mapped TextSpan.end is exclusive throughout the codebase, so an offset exactly at a mapping's span.end lies outside that mapping. Replace the inclusive <= span.end check with an exclusive - #10017

Merged
orizi merged 1 commit into
mainfrom
orizi/06-01-fix_semantic_use_exclusive_upper_bound_in_expansionoffset_mapped_textspan.end_is_exclusive_throughout_the_codebase_so_an_offset_exactly_at_a_mapping_s_span.end_lies_outside_that_mapping._replace_the_inclusive_span.end_chec
Jun 1, 2026
Merged

orizi merged 1 commit into
mainfrom
orizi/06-01-fix_semantic_use_exclusive_upper_bound_in_expansionoffset_mapped_textspan.end_is_exclusive_throughout_the_codebase_so_an_offset_exactly_at_a_mapping_s_span.end_lies_outside_that_mapping._replace_the_inclusive_span.end_chec

Conversation

@orizi

@orizi orizi commented Jun 1, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

Replaces the inclusive range check mapping.span.start <= self.0 && self.0 <= mapping.span.end with an exclusive range check using (mapping.span.start..mapping.span.end).contains(&self.0) in the ExpansionOffset::mapped method.


Type of change

Please check one:

  • Bug fix (fixes incorrect behavior)
  • New feature
  • Performance improvement
  • Documentation change with concrete technical impact
  • Style, wording, formatting, or typo-only change

Why is this change needed?

The previous span containment check used <= on both ends, making it an inclusive range on the end boundary. Using the standard Range::contains method with an exclusive upper bound is more idiomatic Rust and aligns with how span/offset ranges are typically handled (exclusive end).


What was the behavior or documentation before?

The mapping lookup included mapping.span.end as a valid position, treating the range as fully inclusive (start <= offset <= end).


What is the behavior or documentation after?

The mapping lookup uses an exclusive upper bound (start <= offset < end), expressed via (mapping.span.start..mapping.span.end).contains(&self.0).


Related issue or discussion (if any)

N/A


Additional context

Care should be taken to verify that no existing behavior depended on the end offset being inclusive, as this is a subtle semantic change in the range boundary.

TextSpan.end is exclusive throughout the codebase, so an offset
  exactly at a mapping's span.end lies outside that mapping. Replace the
  inclusive `<= span.end` check with an exclusive range so a boundary offset
  resolves to the mapping that actually contains it (or to none), instead of
  matching the preceding adjacent mapping.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@reviewable-StarkWare

Copy link
Copy Markdown

This change is Reviewable

@orizi
orizi marked this pull request as ready for review June 1, 2026 07:35
@cursor

cursor Bot commented Jun 1, 2026 •

Copy link
Copy Markdown

PR Summary

Low Risk
Single-line boundary fix in macro code-mapping lookup; low risk unless something relied on inclusive span.end matching.

Overview
ExpansionOffset::mapped now treats each CodeMapping span as half-open (start <= offset < end) instead of including span.end, matching how TextSpan / offset ranges are used elsewhere (e.g. translate_location intersection checks).

That only changes behavior when an expansion offset sits exactly on a mapping’s end boundary—such positions no longer map through that mapping and macro hygiene may walk to a parent environment instead.

Reviewed by Cursor Bugbot for commit 21290ce. Bugbot is set up for automated code reviews on this repo. Configure here.

@TomerStarkware TomerStarkware left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

:lgtm:

@TomerStarkware reviewed 1 file and all commit messages, and made 1 comment.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on eytan-starkware).

@orizi
orizi added this pull request to the merge queue Jun 1, 2026
Merged via the queue into main with commit acb8d71 Jun 1, 2026
54 checks passed
@orizi
orizi deleted the orizi/06-01-fix_semantic_use_exclusive_upper_bound_in_expansionoffset_mapped_textspan.end_is_exclusive_throughout_the_codebase_so_an_offset_exactly_at_a_mapping_s_span.end_lies_outside_that_mapping._replace_the_inclusive_span.end_chec branch June 1, 2026 09:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants