Fix multi-line Javadoc dropped when file and host line endings differ (#97)

[paulirwin]

Fixes #97.

The bug

CommentsHelper.ConvertDocComment split Javadoc content on Environment.NewLine:

comment.getContent().Split([Environment.NewLine], StringSplitOptions.None)

JavaParser's getContent() preserves the line endings of the parsed file, which are independent of the host OS. I confirmed this with a throwaway probe: CRLF source yields content with 3 CRs, LF-only source yields 0.

So when the two disagree — most commonly a Unix-line-ending file converted on Windows, which is exactly what the reporter narrowed it down to — the content stays one unsplit line, the per-line regex never matches, and the Javadoc is dropped from the output entirely.

Single-line /** ... */ comments were unaffected because they contain no newline to split on. That's why the bug appeared specific to multi-line Javadoc.

Verification

Rather than assume, I reproduced it: on unmodified master, patching the split to "\r\n" (simulating a Windows host) makes the new tests fail with the Javadoc completely absent — no <summary>, no <param>. With the fix, all cases pass.

The change

• Added SplitLines(), which normalizes line endings before splitting, and applied it to the three places that split text originating from the Java source. FormatAsBlockComment already did this correctly by hand and now shares the helper.
• Added NormalizeLineEndings() on the raw comment-trivia paths so comment content adopts the generated file's line endings instead of leaking the Java file's, consistent with the existing Whitespace.NewLine convention.
• The remaining Environment.NewLine uses are all on the output side — including AdjustBlockCommentIndentation, which splits trivia we generate ourselves — and are correct as-is. Only the input-side splits were platform-sensitive.

Tests

Two new theories in CommentTests.cs, each run against both \n and \r\n input.

Worth flagging: there was previously no test anywhere asserting Javadoc → <summary>/<param>/<returns>/<exception> output — every other suite sets IncludeComments = false, so that path was entirely uncovered. These tests close that gap as well.

Full suite: 382/382 passing, 0 build warnings.

Out of scope

Two pre-existing issues I noticed and left alone, each confirmed to reproduce on master independently of this change:

• Generated output has mixed line endings because Roslyn's NormalizeWhitespace() emits \r\n regardless of platform — this happens even for a file containing no comments.
• The CLI's file mode ignored the package declaration and dropped the type for one of my test inputs.

Happy to look into either separately.

🤖 Generated with Claude Code