ILSpy

9511 Commits

54 Branches

94 Tags

91 MiB

Tree: e2b236b994

Commit Graph

Author	SHA1	Message	Date
Siegfried Pammer	79b2ebcb9d	Pin in-parameter binding behavior for span conversions Compiling probes with the C# 14 compiler establishes the matrix: a value argument binds to an 'in ReadOnlySpan<T>' parameter with and without the span conversion (a temporary is created), while an explicit 'in' argument demands the parameter's own type (CS1503); and for a by-value/'in' overload pair, a call without 'in' picks the by-value overload - also through the span conversion - while 'in' at the call site makes the in-overload the only candidate (CS1615 with a conversion). The fixture pins the decompiler side of the same matrix: 'in' must survive decompilation where it disambiguates the overload pair, and the folded span-conversion argument must re-resolve to the by-value winner. The resolver unit tests pin applicability and betterness directly. All of these were green as written - they fence the implicit-in cast stripping and the recheck ladder against regressions rather than fixing a defect. Part of #829. Assisted-by: Claude:claude-fable-5:Claude Code	1 month ago
Siegfried Pammer	cd181b3f08	Fold C# 14 implicit span conversions instead of printing their helpers The C# 14 compiler lowers implicit span conversions to calls - MemoryExtensions.AsSpan(string), ReadOnlySpan<T>.CastUp, and the span op_Implicit operators - so decompiled code showed the lowered form even though the conversion and betterness layers already implement the C# 14 rules. CallBuilder now folds those helper calls back into conversions, riding the existing mechanism: the conversion is built as an explicit cast, consumption sites make it implicit where the context allows, and the overload-resolution recheck re-adds a cast when the bare argument would bind to a different overload (which canonicalizes deliberate AsSpan disambiguations to the equivalent explicit span cast). Span conversions compose, so CastCanBeMadeImplicit lets a direct input-to-target span conversion replace a chained pair; and an rvalue bound to an in parameter gets the same chance to shed the cast as a by-value argument, since ChangeDirectionExpressionTo bypasses the by-value strip. Part of #829. Assisted-by: Claude:claude-fable-5:Claude Code	1 month ago
Siegfried Pammer	6bd800fadd	Add pretty tests for C# 14 first-class span types The green FirstClassSpanTypes fixture pins overload-resolution behavior the decompiler already gets right under the C# 14 implicit span conversions: calls picking the new betterness winners (ReadOnlySpan over Span/object/IEnumerable, ReadOnlySpan<string> over object[] and ReadOnlySpan<object>, MemoryExtensions.Contains over Enumerable.Contains) round-trip as plain calls, while calls picking the losing overload keep their disambiguating casts and Enumerable.Contains stays in static call form. Extension methods on span-convertible receivers, generic inference through span conversions, params betterness, and array-to-span returns are covered too. All winners were verified by executing probes compiled at LangVersion 13 vs 14. The FirstClassSpanConversions fixture is Assert.Ignore'd (#829): it specs the desired folding of compiler-emitted span-conversion helpers back into implicit conversions - MemoryExtensions.AsSpan(string), ReadOnlySpan<T>.CastUp for span variance, and covariant-array/in-arg conversions - which the decompiler currently renders as explicit helper calls or casts (recompilable and semantics-preserving, just not minimal). Both roslyn-latest configs compile the fixture and fail only at the output comparison. Assisted-by: Claude:claude-fable-5:Claude Code	1 month ago

Author

SHA1

Message

Date

Siegfried Pammer

79b2ebcb9d

Pin in-parameter binding behavior for span conversions

Compiling probes with the C# 14 compiler establishes the matrix: a value
argument binds to an 'in ReadOnlySpan<T>' parameter with and without the
span conversion (a temporary is created), while an explicit 'in' argument
demands the parameter's own type (CS1503); and for a by-value/'in' overload
pair, a call without 'in' picks the by-value overload - also through the
span conversion - while 'in' at the call site makes the in-overload the
only candidate (CS1615 with a conversion).

The fixture pins the decompiler side of the same matrix: 'in' must survive
decompilation where it disambiguates the overload pair, and the folded
span-conversion argument must re-resolve to the by-value winner. The
resolver unit tests pin applicability and betterness directly. All of these
were green as written - they fence the implicit-in cast stripping and the
recheck ladder against regressions rather than fixing a defect.

Part of #829.

Assisted-by: Claude:claude-fable-5:Claude Code

1 month ago

Siegfried Pammer

cd181b3f08

Fold C# 14 implicit span conversions instead of printing their helpers

The C# 14 compiler lowers implicit span conversions to calls -
MemoryExtensions.AsSpan(string), ReadOnlySpan<T>.CastUp, and the span
op_Implicit operators - so decompiled code showed the lowered form even
though the conversion and betterness layers already implement the C# 14
rules. CallBuilder now folds those helper calls back into conversions,
riding the existing mechanism: the conversion is built as an explicit
cast, consumption sites make it implicit where the context allows, and
the overload-resolution recheck re-adds a cast when the bare argument
would bind to a different overload (which canonicalizes deliberate
AsSpan disambiguations to the equivalent explicit span cast).

Span conversions compose, so CastCanBeMadeImplicit lets a direct
input-to-target span conversion replace a chained pair; and an rvalue
bound to an in parameter gets the same chance to shed the cast as a
by-value argument, since ChangeDirectionExpressionTo bypasses the
by-value strip.

Part of #829.

Assisted-by: Claude:claude-fable-5:Claude Code

1 month ago

Siegfried Pammer

6bd800fadd

Add pretty tests for C# 14 first-class span types

The green FirstClassSpanTypes fixture pins overload-resolution behavior
the decompiler already gets right under the C# 14 implicit span
conversions: calls picking the new betterness winners (ReadOnlySpan
over Span/object/IEnumerable, ReadOnlySpan<string> over object[] and
ReadOnlySpan<object>, MemoryExtensions.Contains over
Enumerable.Contains) round-trip as plain calls, while calls picking the
losing overload keep their disambiguating casts and Enumerable.Contains
stays in static call form. Extension methods on span-convertible
receivers, generic inference through span conversions, params
betterness, and array-to-span returns are covered too. All winners were
verified by executing probes compiled at LangVersion 13 vs 14.

The FirstClassSpanConversions fixture is Assert.Ignore'd (#829): it
specs the desired folding of compiler-emitted span-conversion helpers
back into implicit conversions - MemoryExtensions.AsSpan(string),
ReadOnlySpan<T>.CastUp for span variance, and covariant-array/in-arg
conversions - which the decompiler currently renders as explicit helper
calls or casts (recompilable and semantics-preserving, just not
minimal). Both roslyn-latest configs compile the fixture and fail only
at the output comparison.

Assisted-by: Claude:claude-fable-5:Claude Code

1 month ago

3 Commits (e2b236b9940e8aeb81bf355147bb6937e7a8e04d)