Repository navigation
Windows: Java method gets no Parameter nodes in test_parameter_nodes_languages_end_to_end #2160
Description
Deterministic on Windows, passes on macOS. Found on PR #1978, whose diff (cross-service flow) touches no Java code.
Failing (run 35789039349, head 2aa373c, rebased on main at ~21:30 on 2026-09-22), in both Unit Tests (windows-latest, py3.12) and (windows-latest, py3.13):
test_parameter_nodes_languages_end_to_end.py::test_every_language_emits_its_declared_parameterstest_parameter_nodes_languages_end_to_end.py::test_of_type_resolves_the_declared_type_in_every_language
{'proj.java.App.App.build(String,Widget)': []} != {'proj.java.App.App.build(String,Widget)': [('name', 0, 'String', False, False), ('w', 1, 'Widget', False, False), ('xs', 2, 'int...', True, False)]}
So the Java method void build(String name, Widget w, int... xs) gets no parameters on Windows; the other languages match.
Checked:
- On macOS, the same file on the same tree passes (3 passed).
- It is not CRLF: rewriting the fixture with
\r\nline endings still passes on macOS. - The last green
mainCI run is b50b363 (20:50). There are 52 commits since then, including fix(java): read the varargs element type of every shape #1976 (Java varargs element types,parsers/java/utils.pyandvariable_analyzer.py), and current main has not finished a Windows run yet.
So this is probably a main regression that every PR rebased past b50b363 will hit on Windows; #1976 is the first suspect but that is unproven.
Activity
vitali87 commentedon Sep 22, 2026
Correction: #1976 is not the cause. Neither PR involved contains it (
git merge-base --is-ancestor ba4e6646is false for both heads).1890599a..57e077dfis five merges: fix(prompts): select orchestrator active projects engine by backend (#1840) #1849, fix(incremental): a cached file that became unreadable is not in sync, not a crash #1994, fix: derive notice licences from the bundle, not the installed wheel #2110, fix(scripts): read classic branch protection beside the rulesets in check_pr_gated (#1957) #1968 and fix: a C# verbatim identifier is not a duplicate-qn marker (#2017) #2113. The only parser changes among them are fix: a C# verbatim identifier is not a duplicate-qn marker (#2017) #2113's (qn_markers.natural_qn/strip_dup_markerreplacing theDUP_QN_MARKERsplits in function_ingest, class_ingest/mixin, method_override, call_resolver and call_processor), so that is the first suspect now.vitali87 commentedon Sep 22, 2026
Retracting my suspect analysis above.
pull_requestCI tests the PR merged into current main, not the head, so checking which commits the two heads contain proved nothing. Root cause (found by 1936): a semantic conflict between #1965's end-to-end test, which expectsbuild(String,Widget), and #1976, which correctly adds the varargs to the Java signature (build(String,Widget,int...)). Main is red on every OS until the expectation is updated; 1936 is fixing it onfix/2160-java-varargs-qn.vitali87 commentedon Sep 24, 2026
Fixed on main by #2173 (
5eba90af). It wasn't Windows-specific: #1976 made the primitive varargs part of the Java signature, and the test still expectedbuild(String,Widget). The expectation is nowbuild(String,Widget,int...), and the test passes on ubuntu, macos and windows in every run since.