You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Glob (*) use statements in statement position (e.g., use core::array::*; inside a function body) now produce a proper diagnostic error (E2075: Unsupported use item in statement) instead of being silently accepted or causing unexpected behavior.
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?
Glob use items inside statement position were not being caught and rejected. The existing logic only iterated over path leaves when processing use statements inside function bodies, but glob (*) paths are not leaves — they are star segments. This meant glob imports in statement position slipped through without a diagnostic, leading to incorrect behavior (regression tracked in #10142).
What was the behavior or documentation before?
A glob use statement such as use core::array::*; inside a function body was not reported as an error, even though glob use items are unsupported in statement position.
What is the behavior or documentation after?
A glob use statement inside a function body now correctly emits:
error[E2075]: Unsupported use item in statement.
--> lib.cairo:2:22
use core::array::*;
^
The fix introduces a call to get_all_path_stars alongside the existing get_all_path_leaves call, so that star segments in a use path are also checked and reported before leaf resolution is attempted.
Low Risk
Narrow diagnostic-only change in statement use processing; no module-level glob behavior change.
Overview
Statement-level use handling only walked path leaves, so glob segments like use core::array::*; were never rejected. The semantic pass now also walks star segments via get_all_path_stars and reports UnsupportedUseItemInStatement (E2075) on each *, before leaf resolution runs.
A regression test covers use core::array::*; inside a function (fixes #10142).
Reviewed by Cursor Bugbot for commit a5e4687. Bugbot is set up for automated code reviews on this repo. Configure here.
The reason will be displayed to describe this comment to others. Learn more.
@TomerStarkware reviewed 2 files and all commit messages, and made 1 comment. Reviewable status: complete! all files reviewed, all discussions resolved (waiting on eytan-starkware).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Glob (
*) use statements in statement position (e.g.,use core::array::*;inside a function body) now produce a proper diagnostic error (E2075: Unsupported use item in statement) instead of being silently accepted or causing unexpected behavior.Type of change
Please check one:
Why is this change needed?
Glob use items inside statement position were not being caught and rejected. The existing logic only iterated over path leaves when processing
usestatements inside function bodies, but glob (*) paths are not leaves — they are star segments. This meant glob imports in statement position slipped through without a diagnostic, leading to incorrect behavior (regression tracked in #10142).What was the behavior or documentation before?
A glob use statement such as
use core::array::*;inside a function body was not reported as an error, even though glob use items are unsupported in statement position.What is the behavior or documentation after?
A glob use statement inside a function body now correctly emits:
Related issue or discussion (if any)
Fixes #10142.
Additional context
The fix introduces a call to
get_all_path_starsalongside the existingget_all_path_leavescall, so that star segments in a use path are also checked and reported before leaf resolution is attempted.