Support TargetObject position in ParserErrors #26649
Conversation
Add support for specifying the column position of a parser error when using the TargetObject IDictionary value. This allows PowerShell to provide a nicely formatted error message that shows the exact position in the line provided where the error occurs.
There was a problem hiding this comment.
Pull request overview
This PR enhances PowerShell's error formatting by adding support for specifying column positions (StartColumn and EndColumn) when using the TargetObject IDictionary approach for parser errors. This allows cmdlets to emit error records with precise column highlighting, similar to native PowerShell parser errors, even though cmdlets cannot throw ParentContainsErrorRecordException.
Key changes:
- Adds optional
StartColumnandEndColumnsupport to the TargetObject error formatting - Provides visual highlighting of the error position using tildes (
~) in the error output - Includes comprehensive validation and fallback behavior for edge cases
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
src/System.Management.Automation/FormatAndOutput/DefaultFormatters/PowerShellCore_format_ps1xml.cs |
Implements logic to read StartColumn/EndColumn from TargetObject, validate them, and generate position highlighting with tildes |
test/powershell/engine/Formatting/ErrorView.Tests.ps1 |
Adds 11 comprehensive test cases covering normal operation, edge cases, type conversion, and invalid input scenarios |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| $line = $_.TargetObject.LineText.Trim() | ||
| $offsetLength = 0 | ||
| $offsetInLine = 0 | ||
| $startColumn = 0 | ||
| if ( | ||
| ([System.Collections.IDictionary]$_.TargetObject).Contains('StartColumn') -and | ||
| [System.Management.Automation.LanguagePrimitives]::TryConvertTo[int]($_.TargetObject.StartColumn, [ref]$startColumn) -and | ||
| $null -ne $startColumn -and | ||
| $startColumn -gt 0 -and | ||
| $startColumn -le $line.Length | ||
| ) { | ||
| $endColumn = 0 | ||
| if (-not ( | ||
| ([System.Collections.IDictionary]$_.TargetObject).Contains('EndColumn') -and | ||
| [System.Management.Automation.LanguagePrimitives]::TryConvertTo[int]($_.TargetObject.EndColumn, [ref]$endColumn) -and | ||
| $null -ne $endColumn -and | ||
| $endColumn -gt $startColumn -and | ||
| $endColumn -le ($line.Length + 1) | ||
| )) { | ||
| $endColumn = $line.Length + 1 | ||
| } | ||
| # Input is expected to be 1-based index to match the extent positioning | ||
| # but we use 0-based indexing below. | ||
| $startColumn -= 1 | ||
| $endColumn -= 1 | ||
| $highlightLine = "$(" " * $startColumn)$("~" * ($endColumn - $startColumn))" | ||
| $offsetLength = $endColumn - $startColumn | ||
| $offsetInLine = $startColumn | ||
| } |
There was a problem hiding this comment.
The LineText is trimmed before validating and using StartColumn/EndColumn positions. If a caller provides LineText with leading or trailing whitespace and specifies column positions based on the original untrimmed text, the positions will be misaligned after trimming.
For example, if LineText is " abc def" (with 2 leading spaces) and StartColumn is 3 (pointing to 'a' in the original text), after trimming the line becomes "abc def" and position 3 would point to 'c' instead.
This should either be documented that LineText should not have leading/trailing whitespace when using StartColumn/EndColumn, or the code should skip trimming when column information is provided.
|
This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days. |
PR Summary
Add support for specifying the column position of a parser error when using the TargetObject IDictionary value. This allows PowerShell to provide a nicely formatted error message that shows the exact position in the line provided where the error occurs.
PR Context
The change made in #19239 made it impossible for cmdlets to emit an ErrorRecord that PowerShell will display with the parsing extent information. A cmdlet cannot throw
ParentContainsErrorRecordExceptionwhich means the checks to use the custom parsing formatting is never used. This results in anErrorRecordwith theParsingErrorto be seen as the below in the default$ErrorView.There exists code right now to use the
TargetObjectto provide a way to produce a more detailed error with the line and script information but doesn't have a way to provide the line position message so it looks just likeThis PR extends the
TargetObjectfunctionality to also supportStartColumnandEndColumnwhich allows the error author to provide enough information to give the line position where the failure actually is.The other benefit is that on consoles that support VT sequences, the problematic position is highlighted
There should be no regression here as the
StartColumnis only used if present and in a valid format.PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright header