Repository navigation
Conversation
wadoon
force-pushed
the
weigl/extendstestmatrix
branch
3 times, most recently
from
July 5, 2026 23:44
6a0b765 to
7df802f
Compare
Contributor
Code coverage overviewLanguages: Java Java / code-coverage/jacoco-ubuntu-latest-21
View coverage of the 7 most impacted files.
ℹ️ Calculations represent line coverage. Results may change as calculations are updated. Updated |
wadoon
force-pushed
the
weigl/extendstestmatrix
branch
2 times, most recently
from
July 6, 2026 04:09
185333e to
b967c17
Compare
wadoon
force-pushed
the
weigl/extendstestmatrix
branch
2 times, most recently
from
August 9, 2026 21:23
375a0d2 to
9e29060
Compare
wadoon
force-pushed
the
weigl/extendstestmatrix
branch
from
August 18, 2026 03:46
a0ec554 to
de08a76
Compare
wadoon
force-pushed
the
weigl/extendstestmatrix
branch
from
September 13, 2026 16:31
de08a76 to
a2f48b4
Compare
wadoon
force-pushed
the
weigl/extendstestmatrix
branch
from
October 17, 2026 17:03
a2f48b4 to
98961bb
Compare
Enabling the Windows matrix in PR #18 surfaced a handful of Windows-only test failures. They are all caused by platform differences in how paths, line endings and file URIs are handled, not by the matrix change itself: - nameResolution: relativized diagnostic paths use backslashes on Windows; normalize to '/' so they match the '//?' expectations. - jmlstub/smt/lsp tests: normalize CRLF produced by System-based line separators before comparing against LF fixtures/text. - .gitattributes: force LF for '*.symbols' expectation fixtures (Windows checkouts would otherwise convert them to CRLF). - lsp: properly handle 'file:///D:/...' Windows drive-letter URIs in the Uri parser instead of stripping 'file://' and leaving a '/D:/...' path that Paths.get resolves against the current drive root; also emit well-formed URIs from the test helper.
testJREClasses generates stubs via reflection from the runtime JDK and compares them byte-for-byte against pinned fixtures. The reflection order of declared fields/constructors/methods is unspecified, and JDK 21.0.13 reordered java.util.List's class-file members, so macos and windows (which resolved Zulu 21.0.13+9) failed while ubuntu passed with its cached 21.0.12. Sort the reflected members explicitly so the stub output no longer depends on the JDK patch release, and regenerate the java.lang.Object / java.lang.String / java.util.List fixtures. Also normalize CRLF vs LF in the fixture comparison so the test is insensitive to the pretty-printed line endings on any platform.
The "Run shell scripts" step crashed on the Windows runner with a
UnicodeEncodeError from the cp1252 console codec while printing the
file-not-found warning for the literal glob 'tools/cli/shell-tests/**'
(pwsh does not expand '**' like bash does).
- pass the directory instead of the glob; shelltester.py already
recurses over the test files with rglob('*.txt')
- reconfigure stdout/stderr to UTF-8 so the emoji/pass markers never
trip over the Windows ANSI codepage
- decode/encode subprocess and file IO as UTF-8 (Java 21 CLIs emit
UTF-8, the fixtures are UTF-8; the locale codec on Windows would be
cp1252)
- on Windows, resolve the first token of the run command via PATHEXT so
'bin/jmltk' correctly maps to the 'bin/jmltk.bat' start script that
installDist generates
| for stream in (sys.stdout, sys.stderr): | ||
| try: | ||
| stream.reconfigure(encoding='utf-8', errors='replace') | ||
| except (AttributeError, OSError, ValueError): |
…nostics The previous Windows run made both shell-tests fail with empty stdout: shutil.which() on an extension-less path returns the bare 'bin/jmltk' POSIX script (installDist also generates it on Windows), so cmd.exe tried to execute a shell script and produced no output. Prefer the platform start scripts (.bat/.cmd/.exe) when resolving the command. Also include the exit code and raw stderr in the failure message, so command-level problems on CI are diagnosable without a second run.
resolve_windows_executable used partition(' ') which strips the separator
before the arguments, producing '...\jmltk.batstubby --help' (missing
the space after the new extension) and cmd.exe failure. Re-insert the
separator when re-assembling the command line.
jmltk bundles 100+ jars, and Gradle's Windows start script generator emits a single `set CLASSPATH=` line enumerating every jar. On the Windows runners that line expands to ~8.8K characters, exceeding cmd.exe's 8191-character line limit, so `jmltk.bat` fails with `The input line is too long.` before the JVM is even started. Post-process the generated Windows scripts (jmltk and jmltk-lsp) to use the Java classpath wildcard form `%APP_HOME%\lib\*` instead of the explicit enumeration, keeping them under the limit and making the distribution actually usable on Windows.
This branch has not been deployed
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.
No description provided.