🦋 Changeset detected

Latest commit: efc0442

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

i believe an ideal fix should identify the actual return type of the callback, but it would be more complex and #6617 (comment) seemed to discourage that approach.

CodSpeed Performance Report

Merging #7564 will not alter performance

_{Comparing turbocrime:fix/void-iterable-callback-return (2903cc4) with main (551bc32)}

Summary

✅ 133 untouched

@ematipico updated with requested changes

strangely, just ready doesn't work for me, so i'm uncertain if i'm meeting CI requirements before i push

this error repeats many times:

error: let chains are only allowed in Rust 2024 or later
 --> <stdin>:1:284002
  |
1 | ...eSlots :: default () ; let mut current_element = elements . next () ; if let Some (element) = & current_element && element . kind () == T ! [void] { slots . mark_present () ; current_e...
  |                                                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Error: process `rustfmt --config newline_style=Unix --config style_edition=2024` failed

Caused by:
    exit status: 1
error: Recipe `gen-all` failed on line 22 with exit code 1
error: Recipe `ready` failed on line 167 with exit code 1

edit: see #7590 #7591

Walkthrough

Updates the nursery lint rule use_iterable_callback_return and its tests. Adds a patch changeset for @biomejs/biome documenting a bug fix. get_function_returns_info no longer treats single-expression arrow bodies as always valued; it now classifies them as value or void by detecting a surrounding unary void expression and returns early for that case. Adds many invalid tests for iterable callbacks returning void and two valid forEach void-return cases. No exported/public API changes.

Suggested reviewers

• arendjr
• siketyan

Pre-merge checks and finishing touches

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

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.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

crates/biome_js_analyze/src/lint/suspicious/use_iterable_callback_return.rs (1)> 279-298: Also handle parenthesised void bodies (e.g. () => (void 0)).

Currently only direct unary void is detected; wrapping it in parentheses won’t be recognised. Unwrapping parentheses before the check avoids false negatives.

i think this is not a good idea

• using parentheses this way is disallowed by the default configuration (they would be removed)
• if we're unwrapping an outer set of parentheses, should we unwrap another nested set of parentheses?
• there will always be another edge case that could unwrap until the entire execution tree of the callback is exhausted

as i said above, an ideal fix should use real type information to identify the return type of the callback. i consider this to be a minimal solution, which satisfies the most common use-case, and which provides an easy technique for developers to satisfy the demands of the rule without applying braces to every arrow callback.

@coderabbitai resolve

@turbocrime Your reasoning is solid. You're absolutely right that handling parenthesized void expressions would create unnecessary complexity:

1. The default formatter configuration would remove those parentheses anyway
2. The question of how many levels to unwrap creates an implementation rabbit hole
3. A minimal fix targeting the common case is more maintainable than trying to handle every edge case

Your approach of detecting direct void expressions in single-expression arrow functions is pragmatic and addresses the core issue reported in #6617. The ideal type-aware solution can be considered for future improvements.