ILSpy

9786 Commits

54 Branches

94 Tags

91 MiB

Tree: 85198271c9

Commit Graph

Author	SHA1	Message	Date
Siegfried Pammer	85198271c9	Fix #3320 : detect dynamic await in pre-Roslyn state machines The C# 5 compiler loads the awaiter into a fresh local before every dynamic call site and before the ICriticalNotifyCompletion type test, and the early non-aggressive inlining refuses to fold those copies. Every await matcher identifies an await by the identity of its awaiter variable, so each copy hid the awaiter from the matcher and the whole await stayed undetected. Each such copy has one store and one load, and after the dynamic call sites are collapsed that load sits in the next instruction, which is the case ILInlining.InlineOne already handles, including the check that the source is not overwritten first. Folding is restricted to the IsCompleted and GetResult call sites and the completion-interface type tests, so dynamic calls in user code keep their locals: a blanket fold retypes unrelated locals of the surrounding method (an enum local decompiled as int plus a cast). Two smaller divergences from the Roslyn shape sat behind that one: the merge block of the AwaitOnCompleted/AwaitUnsafeOnCompleted diamond clears doFinallyBodies before its leave, and the awaiter is restored from its object-typed field with unbox.any rather than castclass. The ILPretty fixture is the state machine from the issue's assembly with its external types stubbed out, so the fix stays guarded where the legacy compiler is unavailable. The Pretty fixture for dynamic await now runs the pre-Roslyn configurations as well, which is the end-to-end guard on Windows; its expected output records that the compiler copies an awaited dynamic value into a local first and emits no debug name for it. The dead stores an optimized build leaves before a try block containing an await are not specific to dynamic - a plain await on a Task produces the same three - so they sit behind an EXPECTED_OUTPUT-only block. Checked against real legacy csc output (/o- and /o+): dynamic await in plain code, loops, try/catch, try/finally and using. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	1 day ago
Siegfried Pammer	8ab3f93f5e	Fix #3704 : keep the static type of a dynamic call target A dynamic call site that names a type passes typeof(T) as its target. When a later argument contains control flow, the compiler stores that typeof in a temporary. ILInlining does not undo this: it inlines a store only into the immediately following instruction, so an intervening statement leaves the typeof behind, and the expression builder printed the temporary instead of the type. Substituting the typeof back into the target slot is not an option either, because a call there has side effects and blocks inlining of the remaining arguments. The type is therefore stored on the instruction. Object creation already did this, but kept the field private, so the expression builder re-derived the type from the target argument and failed on the spilled form. Member invocation gets the same field. Both drop the target from Arguments, so the dead-argument handling removes the store; ArgumentInfo keeps its entry for the target, because the invocation symbol is built from it. The type of an object creation is not nullable: the transform returns before constructing the instruction when it cannot match the typeof, and substitutes the unknown type otherwise. An unresolvable type therefore reaches the expression builder as the unresolved type it is, and prints as `?` like any other, rather than being indistinguishable from a missing one. Those two are also the only binder method kinds that ever see CSharpArgumentInfoFlags.IsStaticType. Every other way of naming a type as the receiver binds statically and leaves only a conversion of the dynamic operand behind. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	3 weeks ago
Siegfried Pammer	c52a0f29f6	Fix #1388 , #1928 : decompile await on dynamic expressions Awaiting a dynamic value lowers GetAwaiter/IsCompleted/GetResult to dynamic callsites, which async decompilation could not recognize: await detection ran before DynamicCallSiteTransform, so the await was emitted as a raw state machine (or crashed in AnalyzeAwaitBlock, #1388). AnalyzeStateMachine now collapses the awaiter callsites per block, folds the runtime ICriticalNotifyCompletion branch the compiler emits for an awaiter not statically known to implement it into the canonical single call, and re-joins the branch chains the collapse leaves so each dynamic await sits in one block. DetectAwaitPattern matches the dynamic GetAwaiter/IsCompleted/GetResult shape and emits `await expr`; a synthesized dynamic GetResult method gives the await and its local the dynamic type. DynamicCallSiteTransform also follows callsite targets spilled into state-machine locals, so an awaited value flowing into a dynamic callsite (e.g. d.Result = await ..., #1928) decompiles too. Assisted-by: Claude:claude-fable-5:Claude Code	2 months ago

Author

SHA1

Message

Date

Siegfried Pammer

85198271c9

Fix #3320 : detect dynamic await in pre-Roslyn state machines

The C# 5 compiler loads the awaiter into a fresh local before every
dynamic call site and before the ICriticalNotifyCompletion type test, and
the early non-aggressive inlining refuses to fold those copies. Every
await matcher identifies an await by the identity of its awaiter
variable, so each copy hid the awaiter from the matcher and the whole
await stayed undetected.

Each such copy has one store and one load, and after the dynamic call
sites are collapsed that load sits in the next instruction, which is the
case ILInlining.InlineOne already handles, including the check that the
source is not overwritten first. Folding is restricted to the IsCompleted
and GetResult call sites and the completion-interface type tests, so
dynamic calls in user code keep their locals: a blanket fold retypes
unrelated locals of the surrounding method (an enum local decompiled as
int plus a cast).

Two smaller divergences from the Roslyn shape sat behind that one: the
merge block of the AwaitOnCompleted/AwaitUnsafeOnCompleted diamond
clears doFinallyBodies before its leave, and the awaiter is restored
from its object-typed field with unbox.any rather than castclass.

The ILPretty fixture is the state machine from the issue's assembly with
its external types stubbed out, so the fix stays guarded where the legacy
compiler is unavailable. The Pretty fixture for dynamic await now runs
the pre-Roslyn configurations as well, which is the end-to-end guard on
Windows; its expected output records that the compiler copies an awaited
dynamic value into a local first and emits no debug name for it. The
dead stores an optimized build leaves before a try block containing an
await are not specific to dynamic - a plain await on a Task produces the
same three - so they sit behind an EXPECTED_OUTPUT-only block.

Checked against real legacy csc output (/o- and /o+): dynamic await in
plain code, loops, try/catch, try/finally and using.

Assisted-by: Claude:claude-opus-5[1m]:Claude Code

1 day ago

Siegfried Pammer

8ab3f93f5e

Fix #3704 : keep the static type of a dynamic call target

A dynamic call site that names a type passes typeof(T) as its target. When
a later argument contains control flow, the compiler stores that typeof in
a temporary. ILInlining does not undo this: it inlines a store only into
the immediately following instruction, so an intervening statement leaves
the typeof behind, and the expression builder printed the temporary instead
of the type. Substituting the typeof back into the target slot is not an
option either, because a call there has side effects and blocks inlining of
the remaining arguments.

The type is therefore stored on the instruction. Object creation already
did this, but kept the field private, so the expression builder re-derived
the type from the target argument and failed on the spilled form. Member
invocation gets the same field. Both drop the target from Arguments, so the
dead-argument handling removes the store; ArgumentInfo keeps its entry for
the target, because the invocation symbol is built from it.

The type of an object creation is not nullable: the transform returns
before constructing the instruction when it cannot match the typeof, and
substitutes the unknown type otherwise. An unresolvable type therefore
reaches the expression builder as the unresolved type it is, and prints as
`?` like any other, rather than being indistinguishable from a missing one.

Those two are also the only binder method kinds that ever see
CSharpArgumentInfoFlags.IsStaticType. Every other way of naming a type as
the receiver binds statically and leaves only a conversion of the dynamic
operand behind.

Assisted-by: Claude:claude-opus-5[1m]:Claude Code

3 weeks ago

Siegfried Pammer

c52a0f29f6

Fix #1388 , #1928 : decompile await on dynamic expressions

Awaiting a dynamic value lowers GetAwaiter/IsCompleted/GetResult to
dynamic callsites, which async decompilation could not recognize:
await detection ran before DynamicCallSiteTransform, so the await was
emitted as a raw state machine (or crashed in AnalyzeAwaitBlock, #1388).

AnalyzeStateMachine now collapses the awaiter callsites per block, folds
the runtime ICriticalNotifyCompletion branch the compiler emits for an
awaiter not statically known to implement it into the canonical single
call, and re-joins the branch chains the collapse leaves so each dynamic
await sits in one block. DetectAwaitPattern matches the dynamic
GetAwaiter/IsCompleted/GetResult shape and emits `await expr`; a
synthesized dynamic GetResult method gives the await and its local the
dynamic type. DynamicCallSiteTransform also follows callsite targets
spilled into state-machine locals, so an awaited value flowing into a
dynamic callsite (e.g. d.Result = await ..., #1928) decompiles too.

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

2 months ago

3 Commits (85198271c9b376fc1a7bf2daa9a744cf9a8f6210)