Method parameter-binding bug with AutomationNull values

[mklement0]

Follow-up from #9997, where @SeeminglyScience notes:

Yeah, looks like a binder bug. There must be a difference in how it approaches converting single item arrays vs more populated arrays. That would explain why the third [test below] works, the binder would still be cached.

Note that the [System.Management.Automation.Internal.AutomationNull]::Value singleton - created with no-output command & {} below - is of type [psobject].

Steps to reproduce

# This FAILS: multi-element array, one element of which is the AutomationNull singleton.
$anull = & {}; [Type]::GetTypeArray(@(0, $anull)).Name | Should -Be 'Int32', 'PSObject'

# This SUCCEEDS - single-element array, with just AutomationNull.
$anull = & {}; [Type]::GetTypeArray(@(, $anull)).Name | Should -Be 'PSObject'

# RETRYING the ORIGINAL command NOW SUDDENLY SUCCEEDS.
$anull = & {}; [Type]::GetTypeArray(@(0, $anull)).Name | Should -Be 'Int32', 'PSObject'

Expected behavior

All tests should succeed.

Actual behavior

The first test fails:

OperationStopped: Object reference not set to an instance of an object.

As mentioned, after the 2nd test has run, the original tests suddenly starts working, due to the binder having been cached.

Environment data

PowerShell Core 7.0.0-preview.5

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.