fix(rust): find test items with a comment between marker and item

[SakarPaisen]

A comment between a test marker and its item made the item disappear from the result.

TestCode matched the marker and the item with (attribute_item)* between them. A comment is not an attribute, so it broke the adjacency and the item was not captured at all. It is neither kept as production code nor excluded as test code, and the #[test] its own comment describes is dropped from the test count with it.

#[test]
// explains the test below
fn isolated_logic() { assert!(true); }

The Decisions query in the same file already handles this for match arms, with [(line_comment) (block_comment)]* between the two arms (#179). This applies the same treatment to the three TestCode patterns, so a comment is a separator rather than a blocker.

Fixes #180

Change

• polyscan/internal/lang/rust/rust.go — the three TestCode patterns now allow [(attribute_item) (line_comment) (block_comment)]* between the marker and the item, and the comment above the query says so.

Tests

Added cases to TestTestCodeIsMarked in polyscan/internal/lang/rust/rust_test.go:

• #[test] followed by a line comment, then the function → test
• #[cfg(test)] followed by a line comment, then the module → test
• #[cfg(all(test, unix))] followed by a block comment, then the module → test
• a commented-out // #[test] above a function → not a test

go test did not run in my environment: go-tree-sitter needs CGO, and this is a Windows machine with no C compiler or WSL, so the package cannot build here. What I did run:

• gofmt -e on both changed files — parses cleanly, no syntax errors.
• gofmt -l reports every file in the repository on this checkout, including ones I did not touch, which is the CRLF artifact of a Windows clone rather than a formatting problem in the change.
• The diff is 2 files, 26 insertions, 4 deletions, with no other changes.

I could not execute the new test cases, so I am not claiming they pass. The query syntax and the expected results follow the existing Decisions pattern (#179) and the documented #[cfg(test)] semantics, but CI on Linux is the first real run.

Which project I ran it on

I did not run polyscan on a project of my own for this change; I worked from the query and its existing tests. Flagging that because the PR template asks for it.

[DaisukeYoda]

@SakarPaisen Thanks for the fix. I checked it locally: the new cases fail on main and pass with this change, and the repro in #180 is fixed. One small thing: the comment above comment_above_test says the commented-out marker "matches too", but the test expects it not to match. Could you change it to something like // A commented-out marker is not a marker.?

I'm also curious how you found polyscan and this issue. Was it through a good-first-issue list, GitHub search, or something else? It would help us understand where contributors come from. And if you have a Rust, Go, JS/TS or C++ project of your own, running polyscan on it and reporting anything that looks wrong would be very welcome.

[SakarPaisen]

Both points done, pushed as 8c723d5 on the same branch.

The comment. You were right, and it said the opposite of the assertion beneath it: A comment on the marker itself matches too sat above a case whose expectation is that the commented-out #[test] does not count. It now reads exactly as you suggested:

// A commented-out marker is not a marker.
// #[test]

Comment only, no behaviour or expectation touched, and the diff is one line in one file. gofmt -e parses it cleanly; I could not run go test here because go-tree-sitter needs CGO and this machine has no C compiler, which is why the acceptance rests on CI rather than on me claiming a green run.

How I found the project — the honest answer, since you asked. I was not a user of polyscan before this. I found it through GitHub search for open issues, filtered to small, self-contained ones, and this one was unassigned, had no comments and no pull request against it. I read CONTRIBUTING.md before touching anything.

I want to be straight about what that means, because I would rather you hear it from me than infer it: I am working through a set of small open-source contributions, one repository at a time, and I pick issues I can actually finish and verify rather than ones I have a personal stake in. That is a different motivation from someone who uses the tool daily, and you should weigh the contribution on its merits accordingly.

What I can say for the work itself: I read the surrounding tests before changing anything, the change is confined to the case you pointed at, and I did not touch the expectation. If the broader issue is not one you want outside help on, close this and I will not take it personally, no reply needed.

[DaisukeYoda]

@SakarPaisen okay Thanks. LGTM!