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	ffbd2055b0	Pin disambiguators for constraints on sibling method type parameters The chain cases in the fixture route T : TOuter through a class-level type parameter; the variant where the dependency target is a sibling method type parameter (M<T, U> with T : U) was uncovered. It pins the same alignment from a different angle: csc rejects 'class' with CS8665 when U is merely class-constrained and requires 'default', but accepts 'class' when U carries a class-type constraint, matching what the tri-state IsReferenceType derives. Both directions were verified against csc before adding the expected output. Assisted-by: Claude:claude-fable-5:Claude Code	2 months ago
Sebastien Lebreton	ee2d747862	Pin the allows ref struct interaction on nullable overrides allows ref struct is inherited implicitly, so restating it on an override is CS0460 even alongside a legal disambiguator. Roslyn still re-emits the byreflike flag on the override's own type parameter, and the general constraint printer turns that flag back into source, so the disambiguator stays legal only as long as it is built separately. Cover a C# 13 base whose annotated and plain methods both allow ref structs. Assisted-by: Copilot:claude-opus-5:GitHub Copilot CLI	2 months ago
Sebastien Lebreton	0e600382b0	Classify nullable override disambiguators by reference type A class-type constraint such as Stream or Delegate sets no ReferenceTypeConstraint flag, so keying the disambiguator off that flag gave those overrides the default constraint, which is CS8822, and the output still did not recompile. The restated disambiguator leaves no metadata trace of its own, so the choice has to follow from whether the inherited constraints make the type parameter a reference type, a value type, or neither. Matching the annotated type parameters by identity rather than by owner kind and index also keeps a specialized signature from contributing a foreign type parameter that happens to share an index. Assisted-by: Copilot:claude-opus-5:GitHub Copilot CLI	2 months ago
Sebastien Lebreton	008cf7a5d1	Fix #3909 : emit nullable override disambiguators Override constraints are normally inherited and omitted, but nullable type parameters still require class or default to distinguish annotations from Nullable<T>. Derive that legal discriminator from the method metadata. Assisted-by: Copilot:gpt-5.6-sol:GitHub Copilot CLI Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 86d2918e-5a24-48b4-9a86-41d331ec3720	2 months ago