pimhwang/ILSpy - ILSpy - git.quantfans.net

Author	SHA1	Message	Date
Siegfried Pammer	01895fbab7	Merge tuple element names during type-inference fixing When fixing a type parameter, Roslyn merges the tuple element names of bounds that are identical apart from those names: names are kept where all bounds agree and dropped where they conflict (MergeTupleNames in Roslyn's MethodTypeInference.cs). The C# standard does not describe this step. Without it, fixing either kept the first bound's names verbatim or, with two exact bounds differing only in names, failed outright - so inferred tuple types could carry names csc would not produce. All merged-name expectations are csc-verified. Nullability is deliberately not merged: Roslyn derives it from the variance of the position, which this implementation does not track, so bounds that differ in it stay distinct and fixing fails as before rather than inventing an annotation. Assisted-by: Claude:claude-fable-5:Claude Code Assisted-by: Claude:claude-opus-5[1m]:Claude Code	1 month ago
Siegfried Pammer	d07362bfce	Add tests for tuple element name merging in type inference The C# standard does not mention tuple element names in type inference, but csc merges names across bounds that differ only by them: names are kept where all bounds agree and dropped where they conflict (Roslyn's MergeTupleNames). All three expectations are verified against csc. The two live tests are red at this commit: without merging, fixing keeps the first bound's element names verbatim. The multiple-exact- bounds case additionally requires AddExactBound to compare bounds modulo element names; it stays ignored until that is implemented. Assisted-by: Claude:claude-fable-5:Claude Code	1 month ago
Siegfried Pammer	132b33e530	Cover the C# standard type-inference rules in TypeInferenceTests Walks the inference algorithm of the standard (draft-v11, 12.6.3) and adds a test per rule that the revived NRefactory suite did not already exercise: exact inference for ref parameters and its non-applicability of the base-type walk, explicit lambda parameter types, exact/upper bound inference through arrays, nullables and variance nesting, the unique-base-type restriction, value-type elements forcing exact inference, conflicting exact bounds, and best common type. Two rules are pinned as ignored tests because the implementation does not follow the standard yet: a value argument to an 'in' parameter infers no bound (12.6.3.7 wants a lower-bound inference), and tuple literals are not inferred elementwise (12.6.3.7/12.6.3.8). Both tests assert the csc-verified result and should go green when the rules are implemented. Nullable unwrapping in exact and upper-bound inferences needs no dedicated code path in this implementation: T? is represented as the constructed type Nullable<T>, so the constructed-type case already produces the elementwise exact inference the standard asks for; the new tests pin that equivalence. Function-pointer inference rules and the explicit-return-type inference of 12.6.3.15 remain untested: the former needs a MetadataModule to construct FunctionPointerType, the latter is not representable in LambdaResolveResult. Assisted-by: Claude:claude-fable-5:Claude Code	2 months ago
Siegfried Pammer	e7f42d1b3c	Revive TypeInferenceTests from NRefactory The direct unit tests for TypeInference were lost when the NRefactory sources were replaced by the NuGet package (`e88120cb4`); since then the class had no dedicated coverage and ConversionTests still pointed to a test that no longer existed. Ported to the current type system API and NUnit constraint asserts. The two tests NRefactory ignored on .NET 4.5 now pin the covariant IReadOnlyList<T> results, since the test compilation uses the 4.5-era reference mscorlib; the common-subtype list test gains the ReadOnlyCollectionBuilder<T> candidates contributed by System.Core, which the NRefactory compilation did not reference. Also includes the seven tests that only exist in upstream icsharpcode/NRefactory (async lambdas, NullablePick, CoContraPick, bug 9300, user-defined-conversion bounds). Upstream wrote them against its source-based resolver harness, which this repo does not have, so they are reexpressed as direct InferTypeArguments calls using mock lambdas and helper types declared in the test assembly. Upstream's InferFromImplicitAsyncLambda was missing its [Test] attribute and never actually ran; here it does. Assisted-by: Claude:claude-fable-5:Claude Code	2 months ago