fix: package-comments false positive on CRLF sources

[Eljees]

fix: package-comments false positive on CRLF sources

Closes #607

Motivation

On a file with CRLF line endings, package-comments reports
package comment is detached for a package comment that is directly
attached to the package clause. The reporter's file from #607:

/*
Package main has a multi-line comment.
Its line endings have a carriage return.
*/
package main

main_crlf.go:4:1: package comment is detached; there should be no blank lines between it and the package statement

Cause

rule/package_comments.go derives the end of the doc comment from
lastCG.End(). ast.Comment.End() is Slash + len(Text), and the scanner
strips carriage returns from Text, so on CRLF sources End() points before
the real end of a block comment — by one byte per stripped \r
(golang/go#41197, which the Go team closed as unfixable in the parser for
compatibility reasons).

For the file above the comment really ends on line 4, but End() resolves to
line 3, so endPos.Line+1 < pkgPos.Line (4 < 5) holds and the rule fires.
The same drift also mis-anchors genuine findings: with CRLF the failure is
reported one line above the blank line it is meant to point at.

Fix

Compute the end line from the comment's own start position plus the number of
line breaks the comment contains. That is exact by construction and does not
depend on line endings at all:

lastComment := cg.List[len(cg.List)-1]
return file.ToPosition(lastComment.Slash).Line + strings.Count(lastComment.Text, "\n")

No new dependency, no line-ending detection, no heuristic.

Tests

testdata/package_comments/ holds three CRLF fixtures, pinned to CRLF by a
local .gitattributes (*.go text eol=crlf) so they stay CRLF on the Linux CI
checkout too:

fixture	expectation
issue607_not_match.go	the reporter's file — nothing reported
issue607_match.go	genuinely detached comment — still reported, anchored on the blank line
issue607_drift_not_match.go	block comment whose end drifts by more than one line — nothing reported

Before the change all three fail (two false positives and one wrong anchor);
after it go test ./... is green, and revive --config revive.toml and
golangci-lint run are clean.

Note on the earlier attempt

#1247 tried endLine + 1 whenever the file ends with CRLF and was withdrawn.
The drift is not a constant: it equals the number of carriage returns stripped
from the comment, so a +1 correction still misses
issue607_drift_not_match.go, and it flips the existing
testdata/golint/package_doc5.go expectation to a false negative whenever that
fixture is checked out with CRLF (which is what happens on Windows with
core.autocrlf=true). The computation above has neither problem.

[Eljees]

Ping — this one and #1764 have been open since 7 August with no review.

Worth flagging in case it is not obvious from your side: no CI has run on either of them. Every check suite on both PRs sits at action_required, which is GitHub waiting for a maintainer to approve a workflow run for a first-time contributor. I cannot trigger that myself, so the absence of green checks is not a signal about the changes.

The two are independent and can be taken in either order.