pimhwang/ILSpy - ILSpy - git.quantfans.net

Author	SHA1	Message	Date
Christoph Wille	fe9f6db3ee	Emit C# 7.1 default literals where the context supplies the type Shortening default(T) is the same problem as removing the redundant cast around a lambda whose delegate type the context already fixes, so it uses the same mechanism: ConvertTo makes the explicit type implicit when the conversion is an identity conversion and the caller allows an implicit one. The literal keeps the type it was shortened from, so any later conversion to a different type - or any context that requires an explicit type, such as an overload resolution recheck falling back to CastArguments - can spell default(T) out again. That keeps the value intact where the bare literal would change it, e.g. "object o = default(SomeStruct)", which boxes a non-null struct while "default" would be null. Because the shortened literal resolves to DefaultLiteralResolveResult, CallBuilder's existing overload resolution recheck sees a real default literal and rejects ambiguous calls on its own; no separate bookkeeping about which arguments may stay untyped is needed. Only the contexts that supply no target type at all restore the explicit form: an awaited expression, and arguments of operator methods, which later become operator or cast syntax rather than calls. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	4 weeks ago
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