Analyzer for Type Reassignment in `foreach` Loop

[aolszowka]

Summary of the new feature
Consider the following script:

if ($true) {
    [String]$MyVar = "Blah"
}

[int[]]$MyInts = @(1,2,3)
foreach ($MyVar in $MyInts) {
    Write-Host "This is my type [$($MyVar.GetType())]"
}

A naïve C# reading of the above PowerShell would assume that the above would print out:

This is my type [int]
This is my type [int]
This is my type [int]

However this is PowerShell and due to Scoping Rules this actually returns:

This is my type [string]
This is my type [string]
This is my type [string]

Proposed technical implementation details (optional)

This has already burned me once in production.

As far as I can tell there is not an existing analyzer to determine this.

It is unclear if it is even feasible to do this reliably.

What is the latest version of PSScriptAnalyzer at the point of writing

PS > Get-Module | Where-Object {$_.Name -eq 'PSScriptAnalyzer' }

ModuleType Version    PreRelease Name                                ExportedCommands
---------- -------    ---------- ----                                ----------------
Script     1.19.1                PSScriptAnalyzer                    {Get-ScriptAnalyzerRule, Invoke-Formatter, Invoke…

[rjmholt]

However this is PowerShell and due to Scoping Rules this actually returns:

I wouldn't quite have put it this way, but it's certainly true that the attribute on the variable is still there because we're in the same scope.

The unusual thing about PowerShell is that you can attach an attribute to a variable that affects later assignments by forcing a conversion.

The scoping part is more usual; the two instances of the variable are in the same scriptblock, so they live in the same scope. That's a common concept across other languages too.

As far as I can tell there is not an existing analyzer to determine this.

It is unclear if it is even feasible to do this reliably.

Within the same scope things get more possible, but even in the example you give there's a complication; the attribute is applied conditionally, so it's not going to be known statically if it's applied (here the condition is if ($true) { ... }, but in general we won't know if the condition is true or false ahead of time).

I think there have been different rules in the past to deal with things like a variable that's reassigned before it's ever used, but that's a valid thing to do:

$value = 'default'
if ($setting) { $value = $setting }

There's also the issue that the RHS value being assigned to the variable is probably not going to have a type known until runtime:

[string]$var = 'duck'

# Obvious issue
$var = 1

# More subtle case
$var = $otherVar + 2

# No idea
$var = $somethingElse

Really it's also perfectly valid to desire a cast on an attributed variable (that's why the behaviour in PowerShell is to perform the cast rather than throw). But that's why rules are configurable, so different users can have different linting.

So I think the right approach for this rule is something like calling the rule AvoidCastingVariableAssignment and have it look for attributed variables in a local scope and report when that variable is reassigned to something we can't prove to be the attributed type.