feat(#566): check name match kebab-case#579
Conversation
🚀 Performance AnalysisAll benchmarks are within the acceptable range. No critical degradation detected (threshold is 100%). Please refer to the detailed report for more information. Click to see the detailed report
✅ Performance gain: |
Signed-off-by: Yegor Bugayenko <yegor256@gmail.com>
|
Warning Rate limit exceeded@yegor256 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 8 minutes and 8 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
@Marat-Tim somehow, tests are failing here. If you can fix them, we'll merge |
kreinba
left a comment
kreinba
left a comment
There was a problem hiding this comment.
The lint XSL and motive read well and the test fixtures cover the happy path, but CI is red on every mvn matrix job and the canonical-code test almost certainly fails because the parser injects auto-generated names like auto-named-attr-at-4-6 for the >> syntax. Those names contain digits and are not in eo:special, so the for-each selector flags them. The allows-special-names.yaml fixture exercises this [] >> shape but does not assert against the injected name, so the gap is invisible from the single-lint pack and only surfaces under the full mono run. Two inline notes pinned below.
| <xsl:output encoding="UTF-8" method="xml"/> | ||
| <xsl:variable name="pattern" select="'^[a-z]+(-[a-z]+)*$'"/> | ||
| <xsl:template match="/"> | ||
| <defects> |
There was a problem hiding this comment.
The selector only filters via eo:special(@name), which knows about @, λ, and cactoos-prefixed names. Parser-injected names from [] >> (the test pack already has one literal example: auto-named-attr-at-4-6 in packs/single/duplicate-names/catches-conflict-with-auto-name.yaml) contain digits and a non-kebab segment, so this for-each will report them as defects. Either extend eo:special to recognise the auto-named-attr-at-* prefix or add a sibling predicate here that excludes that prefix before the regex check.
| x > f | ||
| [] >> | ||
| foo > @ | ||
| [] > baz ? |
There was a problem hiding this comment.
This input uses [] >> and [] > baz ? but the asserts only check the total defect count. Add an input case whose XMIR contains a name like auto-named-attr-at-4-6 (the same shape the parser produces for >>) and assert it is not reported. Without that case the lint silently regresses on the auto-named path, which is what is taking down acceptsCanonicalCode.
3 participants
In this pull request, I added a new linter that checks whether all object names follow kebab-case using only Latin letters.