An instance compound assignment operator has no callable spelling: its call
sites can only be written as "x op= y" or "x++", and C# requires x to be an
assignable variable whose static type binds the operator the call names. The
reader therefore parks an object-typed receiver in a stack slot typed with the
operator's declaring type, and the passes that would substitute or retype such
a receiver hold back. CallInstruction vetoes unfit receiver replacements
through SatisfiesSlotRestrictionForInlining - not writable, not a storage
location, or of a type that declares a hiding operator of the same name or its
checked/unchecked sibling (a declaration-existence check on the type system,
deliberately not a binding question) - which covers inlining; copy propagation
asks the same check per receiver load, the using-transform hands receiver
loads a writable copy of the read-only using variable, and stack slots that
were typed on purpose keep their type when translated.
Assisted-by: Claude:claude-opus-5:Claude Code
Below C# 7 ref locals are unavailable, so CopyPropagation is allowed to copy
LdFlda/LdElema. When such a copy lands in a StObj target slot whose value is
impure, it violates the invariant checked by StObj.CheckTargetSlot: C# computes
the value to be stored before dereferencing the target, so the exception moves.
ILInlining resolves the same conflict by marking the address as delayed rather
than falling back to a ref local; copy propagation now does the same, which
keeps the generated code unchanged and only repairs the IL.
Unlike inlining, copy propagation has no third arm to fall back to: by the time
DoPropagate runs, the defining store is about to disappear, so every load has to
be replaced and refusing the copy is no longer an option. That decision can only
be made up front, which is what CanPerformCopyPropagation does when ref locals
are requested. The assertion covers the remaining hole, the public Propagate()
entry point, which bypasses that check -- AsyncAwaitDecompiler copies an ldflda
of the builder field through it irrespective of the setting.
Propagating an address also un-inlines its arguments into fresh stack slots, and
those stores are copy-propagation candidates in their own right. They are
inserted before the store being replaced, so the block scan used to step right
past them: a slot loaded more than once could never be inlined back and survived
into the output as a ref local -- for `s.ShortField >>>= 5` the copied ldflda
left behind `stloc C_0(ldloca s)`, printed as `ref CustomStruct reference = ref
s`. Rewinding the scan to the first of those stores lets them propagate too.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
The C# debug-steps view highlights and centers the exact AST node a
transform changed; the ILAst view already had the step tree and
replay-at-step but produced no highlight. Bring it to parity.
IL rendering has no token-writer seam like the C# output visitor, so
per-instruction text spans are recorded by bracketing
ILInstruction.WriteTo via a new INodeTrackingOutput. The dominant
inst.ReplaceWith(newInst) transform pattern detaches the instruction
passed to Step, so ILTransformContext gains EndStep to record the
produced instruction; Stepper additionally records the position's
ancestor chain as fallback candidates before the step-limit throw, so
the "show state before" view -- which halts at the selected step --
still resolves to a surviving ancestor (ultimately the ILFunction).
The highlight-range resolver is shared with the C# language.
Assisted-by: Claude:claude-opus-4-8:Claude Code
CopyPropagation will replace `ref StructWithStringField reference = ref array[0];` with:
```
var x = array;
var y = 0;
```
and then every use of `reference` is replaced with `x[y]`.
This lets us avoid rough locals while preserving the semantics in every case except that we re-order when a NullReferenceException/IndexOutOfRangeException occurs.
The code reordering done by copy propagation could cause the lifetimes of different parts of a split variable to start overlapping. This caused incorrect C# to be generated when the variable was recombined.
This helps clean up the mess left behind when stack slots are not eliminated by the normal transforms.
We previously didn't do this because aggressive copy propagation could confuse the normal transforms; but this is no longer an issue with the new pass ordering.
Siegfried Pammer
Peter Crabtree
Daniel Grunwald
dotnet format
mohe2015
Christoph Wille