Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
6d33896 to
fff512d
Compare
…ubmodule and macro call edges
fff512d to
dacf45d
Compare
2a75dee to
cb089a7
Compare
PR SummaryMedium Risk Overview A new Reviewed by Cursor Bugbot for commit dacf45d. Bugbot is set up for automated code reviews on this repo. Configure here. |
TomerStarkware
left a comment
There was a problem hiding this comment.
@TomerStarkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on orizi).

TL;DR
Introduced a unified
all_crate_modules_for_cachefunction to replace duplicated module traversal logic in cache generation.What changed?
A new
all_crate_modules_for_cachefunction was added tocairo-lang-semanticthat performs a breadth-first traversal of all modules reachable from a crate root, following both submodule and macro call edges. This replaces the previous pattern of usingitertools::chaincombined withmodule_macro_modulescalls scattered acrossgenerate_crate_def_cache,generate_crate_semantic_cache, and the lowering cache generation. Themodule_macro_modulesimport was removed from both the semantic and lowering cache modules in favor of this centralized traversal.How to test?
Run the existing cache-related tests to verify that crate cache generation still correctly captures all modules, including those nested inside macro call modules.
Why make this change?
The previous approach duplicated the logic for enumerating all relevant modules in multiple places, and relied on
module_macro_moduleswith an inlinechain!pattern that was easy to get wrong. Centralizing this traversal intoall_crate_modules_for_cacheensures consistent behavior across def, semantic, and lowering cache generation, and makes the intent — following both submodule and macro call edges — explicit and reusable.