Skip to content

Fix sparse-decoration wrongly flagging void φ as decoration (#1130) - #1133

Merged
yegor256 merged 1 commit into
masterfrom
claude/lints-issue-1130-mbt4l6
Jul 29, 2026
Merged

Fix sparse-decoration wrongly flagging void φ as decoration (#1130)#1133
yegor256 merged 1 commit into
masterfrom
claude/lints-issue-1130-mbt4l6

Conversation

@yegor256

Copy link
Copy Markdown
Member

Closes #1130.

Problem

misc/sparse-decoration.xsl reported "Sparse decoration is prohibited" for a formation whose only attribute is a void φ, i.e. the abstract-interface idiom [@] > input. The predicate checked count(o[...])=1 and o[...][1][@name='φ'], but never checked that the φ child carries a real @base. For [@] > input the parser emits a void φ (@base='∅'), and the lint counted it as a decoration.

A void φ is not a decoration — it is a free attribute the caller must supply. There is nothing to inline and the object has no body. This false-positive hit real objects in objectionary/eo such as eo-runtime/src/main/eo/input.eo and output.eo.

Fix

Add a not(@base='∅') guard to the φ test in the predicate so a void φ is skipped, the same way other lints distinguish a bound φ from a void one.

The issue suggested @base != '∅', but that would break the existing formation-as-decoratee case ([] > @), whose φ carries no @base attribute at all — @base != '∅' evaluates to false when @base is absent. Using not(@base='∅') excludes only void φ while still flagging bound-φ and formation-φ decoratees.

Tests

Added no-sparse-because-void-phi.yaml covering [@] > input, which now yields zero defects. All 348 LtByXslTest#testsAllLintsByEo pack tests pass.


Generated by Claude Code

A formation whose only attribute is a void φ (the abstract-interface
idiom, e.g. `[@] > input`) is not a decoration: there is nothing to
inline and the object has no body. The predicate only checked that the
single child was named φ, so the parser's void φ (`@base='∅'`) was
counted as a decoratee.

Require the φ child not to be void (`not(@base='∅')`), mirroring how
other lints distinguish a bound φ from a void one. Using `not(@base='∅')`
rather than `@base != '∅'` keeps flagging the formation-as-decoratee case
(`[] > @`), whose φ carries no `@base` at all.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HHPhak7n4mBMk4QfZgb2iP
@yegor256
yegor256 marked this pull request as ready for review July 29, 2026 06:56
Copilot AI review requested due to automatic review settings July 29, 2026 06:56
@yegor256
yegor256 merged commit c42dc7a into master Jul 29, 2026
22 checks passed

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@yegor256
yegor256 deleted the claude/lints-issue-1130-mbt4l6 branch July 29, 2026 06:56
@0crat

0crat commented Jul 29, 2026

Copy link
Copy Markdown

@yegor256 Thanks for the contribution! You've earned +4 points for this: +16 as a basis; -8 for the lack of code review; -4 for too few (12) hits-of-code. Please, keep them coming. Your running score is +2793; don't forget to check your Zerocracy account too).

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.

sparse-decoration wrongly flags void φ as a decoration

4 participants