tests: test_nup_stand_in's stand-in takes the progress argument (fixes main's Python checks after #1764) #1780

Merged

nullifyshot merged 1 commit from fix/stand-in-test-progress into main

2026-11-10 16:35:27 +00:00

nullifyshot commented

2026-11-10 16:30:47 +00:00

(Migrated from github.com)

The Python source checks have failed on main since #1764, on both Ubuntu and Windows. That PR made make_game.stand_in_damaged_files pass a progress callback, but nx2/test_nup_stand_in.py still replaces nup.stand_in_damaged with a one-argument lambda:

File "nx2/make_game.py", line 354, in stand_in_damaged_files
    done = nup.stand_in_damaged(romfs, file_progress("checked"))
TypeError: <lambda>() takes 1 positional argument but 2 were given

My mistake in #1764: I ran the new test and the two closest checks, but not the whole suite.

What changed

The check's stand-in now takes the optional progress argument.
A new line checks that each call was given a callable progress. That keeps what #1764 added under test instead of only silencing the error.

Tested

On Windows 11 with the v2.0.13 Builder's Python and llvm-mingw:

python -I -B nx2/test_nup_stand_in.py gives stand-ins: ok.
python -I -B tests/run_all.py gives 240 passed, 2 failed, 35 skipped. The two failures come from compiler setup on that PC. They don't touch the file this PR changes:
- test_precompile_compute_guard needs the MSVC target's libraries.
- test_fpx_sticky fails while building a64emit with the Builder's llvm-mingw.
In CI's failed run for #1764, nx2/test_nup_stand_in.py was the only failing check.

The Python source checks have failed on `main` since #1764, on both Ubuntu and Windows. That PR made `make_game.stand_in_damaged_files` pass a progress callback, but `nx2/test_nup_stand_in.py` still replaces `nup.stand_in_damaged` with a one-argument lambda: ``` File "nx2/make_game.py", line 354, in stand_in_damaged_files done = nup.stand_in_damaged(romfs, file_progress("checked")) TypeError: <lambda>() takes 1 positional argument but 2 were given ``` My mistake in #1764: I ran the new test and the two closest checks, but not the whole suite. ### What changed - The check's stand-in now takes the optional `progress` argument. - A new line checks that each call was given a callable progress. That keeps what #1764 added under test instead of only silencing the error. ### Tested On Windows 11 with the v2.0.13 Builder's Python and llvm-mingw: - `python -I -B nx2/test_nup_stand_in.py` gives `stand-ins: ok`. - `python -I -B tests/run_all.py` gives 240 passed, 2 failed, 35 skipped. The two failures come from compiler setup on that PC. They don't touch the file this PR changes: - `test_precompile_compute_guard` needs the MSVC target's libraries. - `test_fpx_sticky` fails while building a64emit with the Builder's llvm-mingw. In CI's failed run for #1764, `nx2/test_nup_stand_in.py` was the only failing check.

hckrman101 (Migrated from github.com) approved these changes

2026-11-10 16:34:49 +00:00

hckrman101 (Migrated from github.com) left a comment

Checked against main: make_game.stand_in_damaged_files calls nup.stand_in_damaged(romfs, file_progress("checked")) positionally, and the real signature is stand_in_damaged(romfs, progress=None), so lambda romfs, progress=None matches both. Main's Windows Python checks failed on this test alone with the <lambda>() takes 1 positional argument but 2 were given TypeError (everything else passed). The new reported == [True, True] check is correct for both calls. Looks good.

Note: draft #1738 changes the same lambda line, so whichever of the two lands second will need a trivial rebase.

Checked against main: make_game.stand_in_damaged_files calls `nup.stand_in_damaged(romfs, file_progress("checked"))` positionally, and the real signature is `stand_in_damaged(romfs, progress=None)`, so `lambda romfs, progress=None` matches both. Main's Windows Python checks failed on this test alone with the `<lambda>() takes 1 positional argument but 2 were given` TypeError (everything else passed). The new `reported == [True, True]` check is correct for both calls. Looks good. Note: draft #1738 changes the same lambda line, so whichever of the two lands second will need a trivial rebase.

Commenting is not possible because the repository is archived.

No reviewers

hckrman101