Skip to content

Fix positional parameter re-binding when parameter appears in multiple sets#27089

Open
powercode wants to merge 1 commit intoPowerShell:masterfrom
powercode:issues/2212
Open

Fix positional parameter re-binding when parameter appears in multiple sets#27089
powercode wants to merge 1 commit intoPowerShell:masterfrom
powercode:issues/2212

Conversation

@powercode
Copy link
Collaborator

@powercode powercode commented Mar 24, 2026

PR Summary

Fixes a bug where a parameter declared with different Position values across multiple parameter sets would be bound twice during positional argument processing, overwriting the correct value.

#2212

Root Cause

EvaluateUnboundPositionalParameters() correctly inserts a parameter into the sorted positional dictionary once per parameter set it belongs to — meaning a parameter that is Position=0 in set Two and Position=1 in set One appears at both dictionary keys. When BindPositionalParametersInSet() iterates these keys in sorted order, it would bind the parameter at position 0 (correctly), then encounter the same parameter again at position 1 and re-bind it — overwriting $First with the argument intended for $Second, and then also binding $Second to that same argument.

Fix

Added a BoundParameters.ContainsKey guard at the top of the outer foreach loop in BindPositionalParametersInSet() (ParameterBinderController.cs) so that a parameter already bound at an earlier position is skipped. The equivalent guard was added to BindPseudoPositionalParameterInSet() in PseudoParameterBinder.cs so that tab-completion behavior stays consistent with runtime binding.

Files Changed

File Change
engine/ParameterBinderController.cs Skip already-bound parameters in BindPositionalParametersInSet()
engine/CommandCompletion/PseudoParameterBinder.cs Same guard in BindPseudoPositionalParameterInSet() for consistency
ParameterBinding.Tests.ps1 5 new Pester tests covering the exact repro and edge cases

Testing

All 5 new CI-tagged tests pass (Tests Passed: 44, Failed: 0) when run against the fixed build on Windows x64.

Reproduction from the original issue:

function Test-It {
    [CmdletBinding()]
    param(
        [Parameter(ParameterSetName = 'Two', Position = 0)]
        [Parameter(ParameterSetName = 'One', Position = 1)]
        [string] $First,

        [Parameter(ParameterSetName = 'Two', Position = 1)]
        [string] $Second
    )
    "$First / $Second"
}

Test-It Hello World   # Before fix: "World / World"  After fix: "Hello / World"

PR Checklist

…e sets

A parameter declared with different Position values across multiple
parameter sets (e.g. Position=0 in set 'Two' and Position=1 in set
'One') was placed in the sorted positional-binding dictionary at every
position it appeared in. BindPositionalParametersInSet() would then
bind the same parameter a second time when the loop reached the later
position, overwriting the correct value with the wrong argument.

Fix: add a BoundParameters.ContainsKey guard at the top of the outer
foreach loop in BindPositionalParametersInSet() so that a parameter
already bound at an earlier position is skipped. Apply the equivalent
guard in PseudoParameterBinder.BindPseudoPositionalParameterInSet()
so that tab-completion is consistent with runtime binding.

Fixes PowerShell#2212
@powercode powercode requested a review from a team as a code owner March 24, 2026 00:29
Copilot AI review requested due to automatic review settings March 24, 2026 00:29
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Fixes a long-standing positional-parameter binding bug where a single parameter declared with different Position values across parameter sets could be bound more than once, causing earlier correct bindings to be overwritten by later positional arguments. The change also aligns tab-completion’s pseudo-binding behavior with runtime binding.

Changes:

  • Add a guard in ParameterBinderController.BindPositionalParametersInSet() to skip positional candidates that are already bound.
  • Add the equivalent guard in PseudoParameterBinder.BindPseudoPositionalParameterInSet() to keep completion consistent with runtime binding.
  • Add new Pester coverage for the runtime binding regression scenarios described in issue #2212.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
test/powershell/Language/Scripting/ParameterBinding.Tests.ps1 Adds regression tests validating correct positional binding across parameter sets for issue #2212.
src/System.Management.Automation/engine/ParameterBinderController.cs Prevents rebinding a parameter that was already positionally bound at an earlier position.
src/System.Management.Automation/engine/CommandCompletion/PseudoParameterBinder.cs Mirrors the runtime binding guard in the completion pseudo-binder to avoid completion-time rebinding.

Comment on lines +1826 to +1832
// Skip parameters that were already bound at a previous position.
// Mirrors the same guard in BindPositionalParametersInSet().
// See https://github.com/PowerShell/PowerShell/issues/2212
if (_boundParameters.ContainsKey(parameter.Parameter.Parameter.Name))
{
continue;
}
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The completion-path fix in BindPseudoPositionalParameterInSet() isn’t covered by a regression test. Since the PR explicitly aims to keep tab-completion consistent with runtime binding, please add a Pester test (e.g., under test/powershell/Host/TabCompletion/*) that reproduces #2212 via TabExpansion2/CommandCompletion::CompleteInput and verifies the already-supplied positional parameter (like -Second) is not suggested after two positional arguments are provided.

Copilot uses AI. Check for mistakes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants