Skip to content

fix(ast_utils): use None sentinel for walk_type_tree seen parameter - #165

Open
SoundMatt wants to merge 1 commit into
COVESA:masterfrom
SoundMatt:fix/ast-utils-mutable-default-seen
Open

fix(ast_utils): use None sentinel for walk_type_tree seen parameter#165
SoundMatt wants to merge 1 commit into
COVESA:masterfrom
SoundMatt:fix/ast-utils-mutable-default-seen

Conversation

@SoundMatt

Copy link
Copy Markdown
Contributor

walk_type_tree declares seen={} as a default argument. Python evaluates default argument values once at function-definition time, so every call that omits seen shares the same dict object. After the first call the dict already contains all visited type names, meaning every subsequent call skips every node and does nothing.

Fix with the standard sentinel pattern: seen=None, initialised to {} inside the function body.

Using a mutable dict as a default argument (`seen={}`) is a classic
Python gotcha: the dict is created once at function-definition time and
shared across all calls.  After the first call the dict retains every
visited type name, so a second call would immediately short-circuit on
every node and do nothing.

Replace with the standard `seen=None` sentinel pattern and initialise
`seen = {}` inside the function body.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Signed-off-by: Matt Jones <47545907+SoundMatt@users.noreply.github.com>
@gunnar-mb

Copy link
Copy Markdown
Collaborator

"After the first call the dict retains every visited type name, so a second call would immediately short-circuit on
every node and do nothing."

OK, fo recursive call to itself, it is the intended behavior that previously "seen" items should be skipped (but seen is explicitly passed to ensure this).

We also have not come across this in other cases because most of the IFEX programs are individually executed and only one instance of walk_type_tree is usually invoked. But this bug would be triggered if two different walk_type_tree sessions are started in the same program.

It looks correct but let's make sure there is a unit-test covering it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants