Skip to content

feat(#34): calculate comment line with abusive char - #1242

Open
VasilevNStas wants to merge 4 commits into
objectionary:masterfrom
VasilevNStas:fix/issue-34-ascii-only
Open

feat(#34): calculate comment line with abusive char#1242
VasilevNStas wants to merge 4 commits into
objectionary:masterfrom
VasilevNStas:fix/issue-34-ascii-only

Conversation

@VasilevNStas

@VasilevNStas VasilevNStas commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

fix #34

What

The ascii-only lint reported the wrong line number for an abusive
(non-ASCII) character sitting in a multi-line comment. This puzzle is
fixed by locating the exact source line of the character.

Why

Consider a program with a two-line comment:

# This comment is fine
# but here привет
[] > foo

The parser merges both lines into a single XMIR node:

<comment line="2">This comment is fine
but here привет</comment>

The @line attribute is not the line of the comment at all: it points
at the line where the parser seals the comment block, i.e. at the next
meta or object after it. With +spdx/+architect metas present the
comment can sit on line 1 while @line says 4. Any arithmetic on top of
@line is therefore unreliable.

How

The comment text is located inside /listing (the full source code the
parser embeds into XMIR). Each line of a comment in the listing starts
with #. The lint finds the first line of the comment there:

head = first line of the comment text (up to the first '\n')
at   = listing.indexOf("# " + head)
line = number of '\n' in listing before `at` + 1
       + number of '\n' before the abusive character in the comment text

This yields the exact source line of the character, regardless of metas.
When /listing is absent (e.g. in integration tests on already-processed
XMIR) or the comment cannot be found, the lint falls back to the old
@line behavior.

Tests

Two new tests cover both shapes:

  • reportsCorrectLineInMultilineComment — abusive char on the second
    line of a two-line comment (previously reported as line 3);
  • reportsCorrectLineInTheMiddle — abusive char in the middle of a
    three-line comment (previously reported as line 3).

The existing unlint-ascii-only-line.eo fixture was adjusted: it used
the old (wrong) line number in +unlint, now it matches the real line
of the comment.

Both mvn test (588 tests) and mvn clean install -Pqulice pass,
plus mvn jmh:benchmark.

@VasilevNStas

Copy link
Copy Markdown
Contributor Author

@volodya-lombrozo plz review this
I've fixed it

Comment thread src/test/resources/org/eolang/lints/non-ascii-middle.eo
Comment thread src/main/java/org/eolang/lints/LtAsciiOnly.java
@VasilevNStas
VasilevNStas force-pushed the fix/issue-34-ascii-only branch from fd4d248 to c25e2ac Compare August 13, 2026 06:47
@VasilevNStas

Copy link
Copy Markdown
Contributor Author

@volodya-lombrozo plz re-review

@VasilevNStas
VasilevNStas force-pushed the fix/issue-34-ascii-only branch 2 times, most recently from 489e1b7 to ae134e4 Compare August 15, 2026 10:14
@github-actions github-actions Bot added the core Changes are made to core parts of the code base label Aug 15, 2026
yegor256 and others added 4 commits August 16, 2026 16:50
…anonymous-formation (objectionary#1262)

* fix(objectionary#1261): stop redundant-attachment from contradicting anonymous-formation

`redundant-attachment` asked for the `>>` to go from every auto-named
object with no referrer, while `anonymous-formation` asked for the name
back on every unnamed formation reaching into `ξ.ρ.*`. A formation that
reads its enclosing scope satisfied neither, so no source could reach
zero warnings.

The set of objects a formation reads from outside itself is now a shared
function, `eo:outer-refs`, used by both lints from their opposite sides.
`redundant-attachment` skips an object whose body holds such a reference,
since dropping its name would only trade one warning for the other.

The rule also fired on auto-names the parser invents on its own, for a
nameless `!` const argument, where the source has no `>>` to delete;
those `.as-bytes` wrappers over `Φ.dataized` are now left alone.

With both false positives gone, `canonical.eo` no longer needs
`+unlint redundant-attachment`: its `[i]`/`[i1]` closures keep the `>>`
they need, and the self-contained `[x]` drops the one it does not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Hw5qR8Jk8bJN2EsjPdMWSK

* docs(objectionary#1261): make vale happy on the redundant-attachment motive

Dropped "over and above" (Oxford comma and word-list rules), the hyphen
in "auto-generated" and the bare "const", none of which the prose styles
accept. Verified with vale 3.17.0, the version CI pins: 0 errors,
0 warnings, 0 suggestions across all 86 motive files.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Hw5qR8Jk8bJN2EsjPdMWSK

---------

Co-authored-by: Claude <noreply@anthropic.com>
@VasilevNStas
VasilevNStas force-pushed the fix/issue-34-ascii-only branch from ae134e4 to b0548f6 Compare August 16, 2026 14:05
@github-actions github-actions Bot removed the core Changes are made to core parts of the code base label Aug 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

AsciiOnly.java:39-42: Calculate comment line number with...

3 participants