The resolve-result hierarchy was split between ICSharpCode.Decompiler.Semantics
and ICSharpCode.Decompiler.CSharp.Resolver, so consumers had to know which half
a given result came from and import both namespaces. All subclasses now live
next to their base class; MethodListWithDeclaringType follows the method group
it describes, and ILVariableResolveResult gets its own file instead of sitting
among the syntax-tree annotation helpers.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Nothing walked the resolve-result graph: the virtual method and its fourteen
overrides only ever called each other, with InvocationResolveResult's chained
base call as the sole call site in the tree.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Both types are consumed well outside the C# output layer - DecompileRun
carries the using scope, and the IL transforms build a resolve context from
it - so living in ICSharpCode.Decompiler.CSharp.TypeSystem misrepresented
where they belong and forced a C#-specific namespace import on every
consumer.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
The resolver's await path has thrown NotImplementedException ever since the
type system rewrite, and nothing else in the repo constructs an
AwaitResolveResult, AliasTypeResolveResult or AliasNamespaceResolveResult:
the decompiler builds await expressions from IL, and alias references never
go through name resolution.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
The resolver comments cited section numbers from the C# 4.0 spec (and a
few from C# 9.0 drafts), which no longer match the published ECMA-334
standard. Renumber them against dotnet/csharpstandard draft-v11; every
reference was checked against the actual section headings. The old
'better conversion from type' subclause (7.5.3.4) no longer exists as
such and its rules live in 12.6.4.5-12.6.4.7, so that comment now says
so instead of pointing at a dead number.
Assisted-by: Claude:claude-fable-5:Claude Code
Dynamic member accesses and invocations carried only the member name
(DynamicMemberResolveResult / DynamicInvocationResolveResult), so
GetSymbol returned null and the editor emitted no reference or hover.
Synthesize a member on the target type - a dynamic field for a member
access, a dynamic-returning method for a member invocation - named after
the accessed member and typed from the callsite delegate: each argument
uses its recorded compile-time type when the binder set one (statically
typed or constant arguments), dynamic otherwise, and the declaring type
comes from the receiver's argument info. Route these through GetSymbol;
TextTokenWriter and the hover renderer already turn an IEntity into a
tooltip. The synthesized members have no metadata token, so they render
a signature on hover but are not navigation targets.
Assisted-by: Claude:claude-fable-5:Claude Code
These have special semantics (number of elements in C# vs. number of bytes in IL), and so pointer arithmetic must go through the special HandlePointerArithmetic() code path --> the normal logic in HandleBinaryNumeric must not ever emit pointer arithmetic.