Fix %<group> expansion to include all members#4
Merged
Conversation
%<group> in command strings was eagerly expanded at parse time, capturing only group members that existed at that point. Groups receiving members from multiple Tupfiles parsed later would get partial snapshots. Now both expansion paths in expand_rule() preserve the literal %<group> pattern, letting resolve_deferred_order_only_edges() expand with full membership after all Tupfiles are parsed. The deferred resolver uses a two-pass approach to accumulate members from same-named groups across directories before replacing. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
db8d27f to
d5e7b9c
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
%<group>expansion — remove eager member-snapshot logic inexpand_rule()that only captured group members parsed so far, causing partial expansion for cross-directory groups%<group>pattern for local groups not in order-only inputs, instead of falling through to an eager callbackresolve_deferred_order_only_edges()now uses a two-pass approach to merge members from same-named groups across directories before replacing, fixing silent member lossDiscovered via the GCC example where
libgmp.aonly got ~16 of 515 objects because subdirectories hadn't all been parsed when%<gmp-objs>was eagerly expanded.Test plan
groups_multi_dir_producers— group receiving members from two directories consumed by a third, verifiescombined.txtcontains both outputs[groups]— 14 test cases, 111 assertions)🤖 Generated with Claude Code