fix: update fypp linemarker-resync patch header for fypp 3.2

[sbryngelson]

Summary

The fypp linemarker-resync patch (added in #1436) was written against an older fypp version where the target hunk began at line 1842 with @@ -1842,11 +1842,16 @@. In fypp 3.2 the same code sits at line 1848 and the surrounding context is smaller, so patch rejects the file as malformed and emits a warning on every mfc.sh invocation:

WARNING > (venv) Failed to apply fypp linemarker-resync patch (fypp version may have changed).

The patch header has been regenerated directly from the installed fypp 3.2 source, producing the correct @@ -1848,7 +1848,13 @@ counts. The actual change to fypp (adding or True to always emit resync linemarkers after single-line $: calls) is identical.

Test plan

• patch applies cleanly against fypp 3.2 with no error
• grep "Always emit a resync marker" $FYPP_PY confirms the patch is active
• No startup warning on ./mfc.sh invocations
• ./mfc.sh precheck passes (all 6 checks)

[github-actions]

Claude Code Review

Head SHA: d2c3a8d

Files changed:

• 1
• toolchain/patches/fypp-linemarker-resync.patch

Findings

or True makes unsync/multiline dead code in the condition

toolchain/patches/fypp-linemarker-resync.patch, changed hunk:

-                if unsync or multiline:
+                if unsync or multiline or True:

or True makes the condition unconditionally True, so the unsync and multiline sub-expressions are never evaluated and serve no purpose. This is effectively dead code in the guard. The comment correctly states the intent ("always emit a resync marker"), but the implementation is inconsistent with it: if the desired behavior is unconditional, the if check should either be removed entirely or written as a clearly-named boolean (always_resync = True) so future patch maintainers don't have to reason through why the condition is always true despite the two meaningful-looking operands.

The risk is that a future maintainer who doesn't notice the or True might "simplify" the condition by removing it, silently regressing the fix. It also means any future upstream change that affects unsync or multiline will have no effect on this code path, which could obscure upgrade conflicts.

The correct minimal patch would be to either omit the if entirely (just run the block unconditionally) or replace the whole condition with if True: to make the intent explicit.

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →