PR Summary

This PR alters the way we compile subpipelines (...), subexpressions $(...) and array expressions @() so that $? is not automatically true after them in the pipeline, but instead depends on the pipeline or statements they executed.

I've added tests for the various behaviours of this, plus some extra tests for pipeline chain operators, which this aids the UX of.

I've structured my changes by commit, so you'll probably find it easier to read this PR from commit to commit.

PR Context

In #9849, the && and || operators were introduced, but currently suffer from the implementation of $?. Specifically:

Write-Error "Bad" || Write-Output "Hi" # Outputs "Hi"

(Write-Error "Bad") || Write-Output "Hi" # Outputs only the error

This makes pipeline chain operators hard to use insofar as they can't be rearranged conveniently by means of parentheses.

In this PR, we change the implementation so that expression-only pipelines only have $? forcibly set when they are a pure value, expressions that actually execute their commands with $? set by the subpipeline.

Further considerations

• This PR likely requires an RFC, which I can begin authoring immediately and will link back here
• Calling Write-Error from within another function still has that function leaving $? as true. I looked into changing that behaviour briefly and it would be fairly complicated.
• This PR doesn't try to expose new mechanisms for cmdlets to set $?

As a final note, looking into how to change this, it seems that while this behaviour may or may not have been originally intended, it occurs because we fix an assumption where all expressions in the pipeline are treated like pure expressions, which are optimised to be evaluated without the pipeline so need a $? = $true added after them. So theoretically this change also is a small (very small) performance improvement.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• 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.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• 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
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).