PSReviewUnusedParameter does not look in scriptblocks

Before submitting a bug report:

• Make sure you are able to repro it on the latest released version
• Perform a quick search for existing issues to check if this bug has already been reported

Steps to reproduce

function f {
    Param($param)

    { $param }
}

Expected behavior

No warnings.

Actual behavior

$param has an PSReviewUnusedParameter warning.

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.2
PSEdition                      Core
GitCommitId                    7.1.2
OS                             Linux 5.10.11-v7+ #1399 SMP Thu Jan 28 12:06:05 GMT 2021
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0


1.19.0

[rjmholt]

This is a tricky one, related to https://github.com/PowerShell/PSScriptAnalyzer/issues/1641.

In your particular example, that parameter is indeed unused. The scriptblock referencing a variable of the same name is not invoked within the scope of that parameter. Instead, the scriptblock will be passed out of the function for later invocation when dynamic scope will mean it will pick up a different value of $param based on the call stack at that time; PowerShell scriptblocks are not closures, so the value of the $param parameter is not exported with the scriptblock returned by this function.

However, in this scenario:

param($param)

& {
    "Hello $param"
}

$param is being used.

However a scenario like that is unusual.

Much more common is something like:

param($Value,, $Weight)

$Value | ForEach-Object { $sum = 0 } { $sum += $_ * $Weight } { $sum }

However, solving this is non-trivial because we (1) must build a list of cmdlets that implicitly invoke their arguments within the current scope and (2) must work out special rules for all of them including a good way of working out how their parameters are bound.

For example compare:

param($X)

Invoke-Command { "Hello $X" }

with:

param($X)

Invoke-Command -ComputerName "MyOtherComputer" { "Hello $X" }

Same command, but the scriptblock invocation semantics are very different, and ideally the rule would fire in the second but not the first case.

That requires a fair amount of work.

[msftbot[bot]]

This issue has been marked as duplicate and has not had any activity for 1 day. It will be closed for housekeeping purposes.