Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix -NoEnumerate behaviour in Write-Output #9069

Merged
merged 5 commits into from Mar 13, 2019

Conversation

@vexx32
Copy link
Contributor

commented Mar 6, 2019

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

Revert "♻️ Clarify method names to avoid confusion"
 Moving commit to another PR

This reverts commit d30ffd6.
@vexx32

This comment has been minimized.

Copy link
Contributor Author

commented Mar 6, 2019

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.

@vexx32 vexx32 marked this pull request as ready for review Mar 6, 2019

@vexx32 vexx32 requested review from JamesWTruher and PaulHigin as code owners Mar 6, 2019

@SteveL-MSFT

This comment has been minimized.

Copy link
Member

commented Mar 6, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented Mar 7, 2019

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

@PaulHigin
Copy link
Contributor

left a comment

LGTM

@iSazonov iSazonov self-assigned this Mar 8, 2019

@iSazonov

This comment has been minimized.

Copy link
Collaborator

commented Mar 8, 2019

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

@daxian-dbw

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 8, 2019

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

Perhaps #2035

@vexx32

This comment has been minimized.

Copy link
Contributor Author

commented Mar 8, 2019

@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

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 8, 2019

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

@daxian-dbw

This comment has been minimized.

Copy link
Member

commented Mar 8, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 8, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 9, 2019

Make alternative internal attribute?

@PrzemyslawKlys

This comment has been minimized.

Copy link

commented Mar 11, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 11, 2019

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

This comment has been minimized.

Copy link

commented Mar 11, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Mar 11, 2019

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 daxian-dbw added this to the 6.2.0 milestone Mar 11, 2019

@daxian-dbw
Copy link
Member

left a comment

LGTM

@iSazonov iSazonov changed the title Write-Output: Fix -NoEnumerate Behaviour Fix -NoEnumerate behaviour in Write-Output Mar 13, 2019

@iSazonov iSazonov merged commit 18d5037 into PowerShell:master Mar 13, 2019

7 of 8 checks passed

CodeFactor 1 issue fixed. 18 issues found.
Details
Codacy/PR Quality Review Up to standards. A positive pull request.
Details
PowerShell-CI-linux #PR-9069-20190306.02 succeeded
Details
PowerShell-CI-macos #PR-9069-20190306.02 succeeded
Details
PowerShell-CI-static-analysis #PR-9069-20190306.01 succeeded
Details
PowerShell-CI-windows #PR-9069-20190306.02 succeeded
Details
WIP Ready for review
Details
license/cla All CLA requirements met.
Details

TravisEz13 added a commit that referenced this pull request Mar 13, 2019

Fix -NoEnumerate behaviour in Write-Output (#9069)
Fix is to preserve input collection type in output.
The regression was caused by #2038
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.