Ternary operator gets formatted to Where-Object

[gogbg]

Prerequisites

• I have written a descriptive issue title.
• I have searched all issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

I'm experiencing issue with the format document functionality which is incorrectly modifying the ternary operator(?) in statements to 'Where-Object'.

PowerShell Version

Name                           Value
----                           -----
PSVersion                      7.2.3
PSEdition                      Core 
GitCommitId                    7.2.3
OS                             Microsoft Windows 10.0.19042
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visual Studio Code Version

1.67.0
57fd6d0195bb9b9d1b49f6da5db789060795de47
x64

Extension Version

[email protected]

Steps to Reproduce

1. Save a powershell script with content:

1 -eq 2 ? 1 : 2

2. Run the vscode format document (Ctrl+K Ctrl+D)

3. The output should be

1 -eq 2 Where-Object 1 : 2

Visuals

Logs

No response

[VOVELEE]

I face the same issue. Please fix :)

[andyleejordan]

Looks to me like this is yet-to-be-supported in PSScriptAnalyzer, #1314

[SydneyhSmith]

Looks like this is also relate to #1362

Could you also please confirm the version of PSSA being run by calling gmo PSScriptAnalyzer in the integrated console?

[gogbg]

@SydneyhSmith I don't have any version of PSScriptAnalyzer, but I believe the vscode powershell extension comes with specific version of the PSScriptAnalyzer included, in this case it's 1.20.0, which is executed "somewhere behind the scenes"

[bergmeister]

I can reproduce this issue only if I use Windows PowerShell to run something like Invoke-ScriptAnalyzer -Path C:\Users\c.bergmeister\git\test.ps1 -Fix. Therefore to me that indicated that the PowerShell Intergrated Console of the VS-Code extension is run using Windows PowerShell and not PowerShell Core. Can you please confirm this by running $PSVersionTable in it, you can pop up that integrated terminal with Ctrl+J.
If it's that then this is by design as Windows PowerShell will never be able to understand the new syntax as PSSA relies on PowerShell's parser. One thing I did point out previously though is that the extension should not apply corrections if there are DiagnosticRecord objects of Severity ParseError @andschwa as we had other issues as well where wrong corrections were being applied because PowerShell's parsers tries a best efforts, see e.g. #1571

[gogbg]

Seems like the latest vscode powershell extension version comes with a breaking change to the setting "powershell.powerShellAdditionalExePaths". It is no longer array but an object, once I adjusted this setting this bug is no longer observable.

Previously it was:

  "powershell.powerShellAdditionalExePaths": [
    {
      "versionName":"PowerShell 7.2.4",
      "exePath":"C:\\ProgramData\\PowerShell\\7.2.4\\pwsh.exe"
    }
  ]

Now(the working setting for [email protected]) is:

  "powershell.powerShellAdditionalExePaths": {
    "PowerShell 7.2.4": "C:\\ProgramData\\PowerShell\\7.2.4\\pwsh.exe"
  },

[andyleejordan]

You are correct @gogbg, more info here: PowerShell/vscode-powershell#3978 So sorry, we took a community PR and did not realize it was a breaking change.

[lzandman]

It seems this issue is still unsolved. It just happened in my editor. I don't get why it was closed. @gogbg

[gogbg]

@lzandman check your vscode config, as I described here #1791 (comment)

[lzandman]

@lzandman check your vscode config, as I described here #1791 (comment)

But that is a response from 2022. It looks like a quick workaround/hack to make things work. Does this mean the underlying issue hasn't actually been resolved and this bug is still present in VSCode?

[gogbg]

@lzandman the issue resolved for me when I adjusted the VSCode PowerShell extension version to PowerShell 7.2.4.