Skip to content

cycle_initial and recover_from_cycle macros generate clippy::double_parens warnings on #[salsa::tracked] macro use #1004

@welf

Description

@welf

In Nightly builds both cycle_initial and recover_from_cycle generate unnecessary parentheses warnings when using #[salsa::tracked] macro and the tracked function doesn't use any additional inputs:

= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_parens
= note: this error originates in the macro salsa::plumbing::unexpected_cycle_recovery which comes from the expansion of the attribute macro salsa::tracked (in Nightly builds, run with -Z macro-backtrace for more info)
= note: this error originates in the macro salsa::plumbing::unexpected_cycle_initial which comes from the expansion of the attribute macro salsa::tracked (in Nightly builds, run with -Z macro-backtrace for more info)

The Problem:

In components/salsa-macro-rules/src/unexpected_cycle_recovery.rs, both macros use this pattern: std::mem::drop(($($other_inputs,)*)); that creates a tuple containing all $other_inputs and drops them.

These macros are invoked from components/salsa-macro-rules/src/setup_tracked_fn.rs:305-316:

  • cycle_initial is called with: (db, $($input_id),*)
  • recover_from_cycle is called with: (db, value, count, $($input_id),*)

When $other_inputs is empty (function has no additional inputs beyond db), the expression ($($other_inputs,)*) expands to () (an empty tuple), resulting in: std::mem::drop(()) and it triggers clippy warnings.

The Fix:

Instead of creating a tuple and dropping it, we should repeat dropping each input individually:

  • instead of std::mem::drop(($($other_inputs,)*));
  • use $(std::mem::drop($other_inputs);)*

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions