feat(#34): calculate comment line with abusive char - #1242
Open
VasilevNStas wants to merge 4 commits into
Open
Conversation
Contributor
Author
|
@volodya-lombrozo plz review this |
volodya-lombrozo
suggested changes
Aug 13, 2026
VasilevNStas
force-pushed
the
fix/issue-34-ascii-only
branch
from
August 13, 2026 06:47
fd4d248 to
c25e2ac
Compare
Contributor
Author
|
@volodya-lombrozo plz re-review |
VasilevNStas
force-pushed
the
fix/issue-34-ascii-only
branch
2 times, most recently
from
August 15, 2026 10:14
489e1b7 to
ae134e4
Compare
…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
force-pushed
the
fix/issue-34-ascii-only
branch
from
August 16, 2026 14:05
ae134e4 to
b0548f6
Compare
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.
fix #34
What
The
ascii-onlylint 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:
The parser merges both lines into a single XMIR node:
The
@lineattribute is not the line of the comment at all: it pointsat the line where the parser seals the comment block, i.e. at the next
meta or object after it. With
+spdx/+architectmetas present thecomment can sit on line 1 while
@linesays 4. Any arithmetic on top of@lineis therefore unreliable.How
The comment text is located inside
/listing(the full source code theparser embeds into XMIR). Each line of a comment in the listing starts
with
#. The lint finds the first line of the comment there:This yields the exact source line of the character, regardless of metas.
When
/listingis absent (e.g. in integration tests on already-processedXMIR) or the comment cannot be found, the lint falls back to the old
@linebehavior.Tests
Two new tests cover both shapes:
reportsCorrectLineInMultilineComment— abusive char on the secondline of a two-line comment (previously reported as line 3);
reportsCorrectLineInTheMiddle— abusive char in the middle of athree-line comment (previously reported as line 3).
The existing
unlint-ascii-only-line.eofixture was adjusted: it usedthe old (wrong) line number in
+unlint, now it matches the real lineof the comment.
Both
mvn test(588 tests) andmvn clean install -Pqulicepass,plus
mvn jmh:benchmark.