Support Int128, UInt128, and Half conversions#27700
Open
infisble wants to merge 2 commits into
Open
Conversation
Add Int128, UInt128, and Half to the built-in numeric conversion cache. Use checked numeric operators for types that do not implement IConvertible and keep PowerShell's rounding behavior for real-to-integer conversions.
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR extends PowerShell’s numeric conversion infrastructure to support System.Int128, System.UInt128, and System.Half across standard conversion paths (including invariant-culture parsing and rounding semantics), addressing #25372.
Changes:
- Registers
Int128,UInt128, andHalfin the numeric type caches and conversion rank logic. - Adds operator-based numeric conversion paths (favoring checked operators) for types that don’t implement
IConvertible, while preserving midpoint rounding behavior for real→integer conversions. - Adds/extends Pester coverage for boolean/null conversions and invariant string parsing (including thousands separators) for the new numeric types.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
src/System.Management.Automation/engine/LanguagePrimitives.cs |
Adds the new numeric types to conversion caches and implements operator-based numeric conversions with rounding/invariant parsing support. |
test/powershell/Language/Parser/Conversions.Tests.ps1 |
Extends casting tests for bool/null and adds numeric→bool cases for Int128, UInt128, and Half. |
test/powershell/engine/Api/LanguagePrimitive.Tests.ps1 |
Adds API-level tests for invariant string parsing and conversion behavior/overflow for Int128, UInt128, and Half. |
Author
|
@microsoft-github-policy-service agree |
Fall back to the existing Convert.ChangeType-based numeric converter when no checked or regular conversion operator is available. Add a regression test for the fallback selection.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Summary
PowerShell users can now use
System.Int128,System.UInt128, andSystem.Halfin the standard numeric conversion paths.This change:
IConvertible;PR Context
Int128,UInt128, andHalfdo not implementIConvertible, so adding them to the existing type arrays alone would still leaveConvert.ChangeTypepaths failing. The operator-based converter handles those types while keeping overflow checks and the existing conversion ranks.Fix #25372
Validation:
Start-PSBuild -Clean -PSModuleRestore -UseNuGetOrgLanguagePrimitive.Tests.ps1andConversions.Tests.ps1: 133 passed, 0 failedPR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright header