Fix -NoEnumerate behaviour in Write-Output

[vexx32]

PR Summary

Write-Output's InputObject parameter was typed as PSObject[]. This was forcing all collections to be enumerated during parameter binding, making -NoEnumerate essentially useless; use of the switch would result in a PSObject[]-typed output collection instead of the usual object[], but it was completely impossible to retain the original collection(s) via the switch.

Fixes #5955, a long-standing regression from Windows PowerShell.

Adds regression test.

As I was digging through the underlying code before I came upon the true cause, I also came across a pair of methods with names that are just asking for misinterpretation. I renamed one of the pairs, the pair with only one reference each. As they are private methods, I doubt this will affect anything much, but it should make maintaining those code paths less confusing going forward. Moved to #9074.

PR Context

See issue #5955 for context.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
    • Add [feature] to your commit messages if the change is significant or affects feature tests

[vexx32]

Reverted the commit. I'll ignore the CodeFactor items for MshCommandRuntime.cs -- most of them look to be the usual Hungarian notation ones that we plan to ignore going forward anyway. 😄

Moved that change to #9074.

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this. We agree that we should fix this to get back to the Windows PowerShell behavior which is the correct behavior.

[iSazonov]

@vexx32 Please open new issue in Docs repo if needed.

[PaulHigin]

LGTM

[iSazonov]

@mklement0 Could you please look the PR before we merge?

[daxian-dbw]

The parameter type of InputObject for Write-Output is psobject[] on Windows PowerShell,

PS:2> Get-Command Write-Output -Syntax

Write-Output [-InputObject] <psobject[]> [-NoEnumerate] [<CommonParameters>]

and it behaves as expected:

PS:3> (Write-Output -NoEnumerate 1, 2).GetType().Name
Object[]
PS:4> (Write-Output -NoEnumerate ([System.Collections.ArrayList] (1, 2))).GetType().Name
ArrayList

So I wonder what is the actual change that breaks it on PowerShell Core ...

[iSazonov]

So I wonder what is the actual change that breaks it on PowerShell Core …

Perhaps #2035

[vexx32]

@daxian-dbw Yeah, I can see where that's confusing... And knowing what PSObject is for more than I used to, I think it makes more sense behaving as it currently does... but I am very sure that sentiment wouldn't necessarily be shared by most PowerShell users.

[daxian-dbw]

Yes, the regression was caused by #2038. See another related issue: #5122
Unfortunately, due to #2038, Write-Output still doesn't behave exactly the same as on Windows PowerShell even with this PR:

# on windows powershell
(Write-Output -NoEnumerate 1).GetType().FullName
> System.Int32

# on powershell core with this PR
(Write-Output -NoEnumerate 1).GetType().FullName
> System.Collections.Generic.List`1[[System.Object, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]

[vexx32]

@daxian-dbw I shall do some digging to see where that occurs and what can be done about it.

[daxian-dbw]

@vexx32 After #2038, the remaining argument are handled in a similar way as params in C#:
if the remaining argument is a collection, then use that collection directly, otherwise, wrap the argument(s) to a List<object>.
I double there is anything we can do in Write-Output to make it behave the same as in Windows PowerShell in those particular cases :(

[vexx32]

Hmm. I guess that makes some sense.

It does seem rather unlikely that folks would deliberately use -NoEnumerate and then not expect a collection to be the result. 🤔

[iSazonov]

Make alternative internal attribute?

[PrzemyslawKlys]

Maybe instead of fixing Write-Output -NoEnumerate (which would be nice of course) behavior for [OutputType()] could be changed to keep output type untouched if it's defined. Right now even without [OutputType()] defined you still get unwrap for a single object.

[vexx32]

Not sure I follow what you mean there. That attribute generally is metadata and more of a documentation attribute that anything else. As far as I know, it has no effect during execution.

Nor do I really see how it would help with this current situation, where -NoEnumerate is simply broken?

[PrzemyslawKlys]

I see. Well, I thought that it's more than metadata. And the only reason I would use NoEnumerate is to preserve Array on function return. If it has other uses, that's cool too.

What I mean is, if that change wouldn't go thru because of other reasons I would still want some other way to have that feature. If it goes thru, that's great.

[vexx32]

Gotcha. Yeah, that might work on a surface level. Unfortunately it would probably mean enumerating the collection twice (once in the parameter binder -> PSObject[], and once before output -> OutputType) which is a bit much imo.

It would also not be retaining the original collection, so if it originally had NoteProperty or other ETS members, they would be stripped. In the few cases where -NoEnumerate are needed, this might be one motivation for using it.

[daxian-dbw]

LGTM