Twenty shapes that no fixture covered: nesting at depth three and at position
zero, inner discards on either side, property and no-conversion targets, and
deconstruction inside try, switch, if/else and while. All but one already
decompile correctly - they are checked in so a future change to
DeconstructionTransform cannot silently drop them.
The one that does not is left commented out with a pointer to #4059 rather than
as a red test: two back-to-back deconstructions share their out-slot
temporaries, and neither is recognized.
#4059
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
The assembly list answered DragOver with the Move effect only. OLE
intersects that answer with the effects the drag source permits, and
sources such as FileLocator Pro only permit Copy, so the negotiation
ended in None and the drop was refused although CF_HDROP was present
and the file path resolved fine. Explorer permits Move, which is why
drops from Explorer kept working. The WPF ILSpy offered Move, Copy and
Link and let the source pick; restore that.
Assisted-by: Claude:claude-fable-5:Claude Code
A merging obfuscator can leave a module referencing two versions of the same
assembly. Loading both split every type they declare into two definitions that
compare unequal, so a signature naming such a type through one reference stopped
matching a base method naming it through the other, and a genuine override was
printed as virtual. ac0ef8a11 (#3253) dropped the lower-version duplicates, but
nothing covered that, and neither of the existing fixture kinds can carry the
three assemblies the situation needs.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Two test fixtures carried their own copy of the 32-byte signature, which
would silently drift from the real one. The signature is now an internal
member of SingleFileBundle and ILSpy.Tests gets internals access to the
decompiler assembly, matching what ILSpyX already grants it.
Assisted-by: Claude:claude-fable-5:Claude Code
IsBundle scanned up to but excluding the last position at which a full
signature fits, so a signature occupying the final 32 bytes of the region
was never compared. Windows hid this: a memory-mapped view there reports
the page-rounded region size, leaving trailing zero bytes after the file.
On Linux and macOS the view length is the exact file length, and the
LoadedPackage bundle tests, whose synthetic bundles end with the
signature, failed there with FromBundle returning null. Real bundles keep
apphost code after the signature, which is why this stayed latent.
Assisted-by: Claude:claude-fable-5:Claude Code
A single-file bundle manifest is attacker-controlled. Opening a compressed
entry pre-allocated a MemoryStream of the declared decompressed size
through an unchecked long-to-int cast, then inflated the whole deflate
stream before comparing lengths. A few-byte payload declaring ~2 GB thus
forced a ~2 GB allocation up front, sizes at or above 2 GB wrapped to a
negative capacity, and a decompression bomb was expanded in full before
the mismatch was noticed (CWE-789, CWE-197).
Grow the buffer only with bytes the deflate stream actually produces and
stop reading one byte past the declared size, which already proves the
entry corrupt. Reject declared sizes that cannot fit a single in-memory
buffer as invalid bundle data. Entry offsets need no extra check: the
UnmanagedMemoryStream over the mapping already validates them against the
view length.
Assisted-by: Claude:claude-fable-5:Claude Code
A .resources file's resource count, type count, name lengths, binary
resource lengths and serialized-object lengths all come from the file
and were only checked for being non-negative before sizing an allocation.
A crafted file can therefore request multi-gigabyte arrays from a
few-hundred-byte payload (CWE-789), turning a click on a resource node
into an out-of-memory condition. The serialization-format kind was
additionally an assert-only check that vanishes in Release builds.
Each element of these counts occupies at least one byte in the stream, so
a value needing more bytes than remain after the current position cannot
be honest. Reject it with the same BadImageFormatException the callers
already handle, and promote the format-kind assert into a real check.
Assisted-by: Claude:claude-fable-5:Claude Code
The JSON parser's value/object/array readers are mutually recursive with
no depth limit, so input nested tens of thousands of levels deep overflows
the stack with an uncatchable StackOverflowException (CWE-674) that kills
the process. This is reachable through DotNetCorePathFinder, which parses
the .deps.json shipped next to an opened assembly, so a crafted manifest
beside a target turns dependency resolution into a clean process kill.
Thread a depth counter through the readers and throw a catchable
JsonParseException once nesting passes a fixed cap. The cap (64) matches
the System.Text.Json default and is far beyond any real dependency graph.
Assisted-by: Claude:claude-fable-5:Claude Code
The search icon tests only exercised the type and field delegations; the
method, property and event arms and the namespace LocationImage fallback
for top-level types were untested.
Assisted-by: Claude:claude-fable-5:Claude Code
The derived-types entries, the compare pane, and the analyzer tree nodes
still built their icons from bare base images (or private duplicates of
the helper logic), losing the accessibility/static overlays and the
kind-specific glyphs (enum value, literal, readonly field, indexer,
P/Invoke, virtual and extension methods). The WPF frontend routes all of
these through the tree nodes' static GetIcon helpers; do the same so
every pane composes icons identically by construction.
Assisted-by: Claude:claude-fable-5:Claude Code
The WPF frontend uses a type-only overlay mapper that shows protected
internal types with the plain protected badge, while members get the
combined protected-internal badge; the Avalonia frontend ran both through
the shared Images.GetOverlay and so badged types differently. Restore the
type-only mapping in TypeTreeNode.GetIcon, which now also covers search
results and every other caller of the helper.
Assisted-by: Claude:claude-fable-5:Claude Code
The search result factory built icons from the bare base images, bypassing
Images.GetIcon, so search results lost the private/internal/protected and
static mini-overlays (and flattened interfaces, structs, enums and delegates
to the class icon; constructors, operators and indexers to the plain member
icons). Delegate to the tree nodes' GetIcon helpers instead, as the WPF
frontend's SearchResultFactory did, so search icons match the assembly tree
by construction. TypeTreeNode and EventTreeNode get the same static GetIcon
extraction the other member tree nodes already had.
Assisted-by: Claude:claude-fable-5:Claude Code
The pane deduped new entries by comparing IModule instances, but analyzer
results live in the type system each analyzer run builds, so the same
member analysed from a result row and from the assembly tree (or from a
re-run analysis after its rows were collapsed away) never matched and got
a second top-level row. The loaded MetadataFile is the identity that
survives across type systems.
Assisted-by: Claude:claude-fable-5:Claude Code
Making a conversion implicit by unwrapping it hands the operand to a
different target type, and a default literal takes its value from that
type: "S? x = new S?(default)" holds a value, while "S? x = default" is
null. Unwrapping the nullable constructor around a shortened literal
therefore turned "S? x = default(S)" into a null nullable. The literal is
spelled out again whenever unwrapping moves it to a type other than the one
it was shortened from.
Converting a using resource to the declared variable type is unconditional
now (except when the declaration says "var", which supplies no type): the
declaration always spells the type out, so any conversion to it may stay
implicit, which is also what shortens default(T) there.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Mutating the DefaultValueExpression is enough here; ConvertTo already hands
out mutated input nodes elsewhere (UnwrapChild), so building a replacement
node and copying the annotations over bought nothing.
The operator special case is easy to mistake for a cosmetic preference,
because the null literal is accepted in the same position: it converts only
to reference and nullable types, so it still narrows operator overload
resolution, whereas the default literal converts to everything and C#
rejects it outright for every binary operator except == and !=.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
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
The pretty-print comparison already treats blank lines, comment-only lines
and preprocessor directives as ignorable, but only when scoring a single
diff entry: they still sat in the line collections handed to the aligner. A
run of #if/#else/#endif around a statement could then push the aligner into
matching an adjacent brace as inserted-and-deleted, failing a test whose
decompiled output was in fact correct. Drop those lines before diffing so
they cannot skew the alignment.
Assisted-by: Claude:claude-opus-4-8:Claude Code
The port dropped IMemberTreeNode from AnalyzerEntityTreeNode, so the
member-based context-menu entries (Analyze, Copy name, ...) no longer
recognised analyzer rows and a result row could not be promoted to a
top-level entry. Top-level rows keep the entry hidden: re-analysing
them is a no-op, and Remove is the entry for those rows.
Assisted-by: Claude:claude-fable-5:Claude Code
The WPF SharpTreeView bound ApplicationCommands.Delete at class level, so
Delete deleted the top-level selection of any tree whose nodes opt in via
CanDelete/Delete -- which is how a top-level analyzer entry was removed
from the Analyzer pane. The Avalonia tree never received that binding;
only the assembly list pane carried a hand-rolled Delete handler for
assemblies, so the analyzer pane lost the key entirely even though its
nodes still implement the deletion overrides.
Moving the gesture back into SharpTreeView restores it for every tree
and lets the pane-specific handler (with its own reselect logic) go.
Assisted-by: Claude:claude-fable-5:Claude Code
WPF translated XButton1/XButton2 into BrowseBack/BrowseForward
commands by itself, so the WPF frontend got the behaviour for free
and the buttons never reached the control under the pointer as a
click. Avalonia has no such translation and KeyBinding cannot express
pointer buttons, so only Alt+Left / Alt+Right survived the migration.
MainWindow now swallows the X-button press while it tunnels (Dock
would otherwise activate the pane under the pointer, AvaloniaEdit
would focus the editor or toggle a folding marker) and routes the
release to the existing DockWorkspace navigation commands.
Navigating also no longer moves the active pane to the editor: the
history target is usually the already-active tab, and Dock's
ActiveDockable setter re-runs InitActiveDockable -> SetFocusedDockable
even for an unchanged value, so re-activating it only moved the
focus. WPF's ActiveTabPage setter was a no-op for the same value.
Assisted-by: Claude:claude-fable-5:Claude Code
Avalonia 12 treats plain Enter/Space on a ListBoxItem as selection
input: the container marks the KeyDown handled before it bubbles, so
SharpTreeView.OnKeyDown never saw the keys and its activation handling
(navigate to the member from an analyzer row, toggle a checkable row)
was dead. Override ShouldTriggerSelection -- the extension point added
for this in Avalonia 12 -- to suppress the selection trigger exactly
for the case OnKeyDown activates instead: a single selected row that
is the row the key landed on. Multi-row selections keep the default
collapse-to-focused-row behaviour.
Assisted-by: Claude:claude-fable-5:Claude Code
DerivedTypesEntryNode.Filter reported Recurse, but the cascade's
Recurse handling force-loads the entry's lazy children and hides the
entry when all of them are hidden. A leaf derived type has no children,
so every entry under "Derived Types" ended up hidden, and the hiding
propagated up the whole derived chain. The WPF tree showed these
entries as matches; Match restores that and also keeps the entries'
children lazy instead of eagerly scanning the assembly list for each
level of the chain.
Assisted-by: Claude:claude-fable-5:Claude Code
The PowerShell host used to sleep for a fixed 300 s, so any run in which
the process walks got slow (as happened on a starved CI runner) lost the
host mid-fixture and failed the remaining tests for the wrong reason.
Waiting on the test host's PID makes the fixture independent of wall
clock and also guarantees the host disappears with the test host even
if the teardown never runs.
Assisted-by: Claude:claude-fable-5:Claude Code
The Windows job runs every test host of the solution concurrently on a
4-core runner. With ICSharpCode.Decompiler.Tests on server GC that host
sits at 98-100% CPU for the whole test step, and the neighbours starve:
the process-module walk in ILSpy.Tests.Windows exceeded its 60 s budget
(OperationCanceledException in NetFrameworkProcessesTests, Release job),
a background sampler measured its own walk over the ~170 runner processes
at 40-170 s instead of a few seconds, and ILSpy.Tests took 685 s instead
of 375 s (Release). Memory was not the constraint: never below 9 GB free,
disk idle. The decompiler suite itself moved little on that box (Debug
1393 s -> 1226 s, Release 664 s -> 751 s). Server GC stays on for machines
the suite has to itself; the Linux job runs the projects one at a time.
Assisted-by: Claude:claude-fable-5:Claude Code
The suite keeps one NUnit worker per logical CPU busy with allocation-heavy
decompiles (223 GB allocated per run), so under workstation GC every
gen0/gen1 collection any worker triggers suspends the whole process.
Measured on a 24-thread Windows box (Debug, ILSpy-tests checked out):
27,229 gen0 / 6,919 gen1 collections and 305 s of total GC pause in a
553 s run, at 45% average CPU. With server GC the same run takes 310 s,
1,251 gen0 / 492 gen1, 14 s of pause, 80% CPU, for the same ~46 min of
processor time; the in-suite roundtrip decompiles drop 2-3x
(Random_TestCase_1 353 s -> 133 s, ExplicitConversions 319 s -> 136 s,
NRefactory_CSharp 337 s -> 156 s). Standalone ilspycmd timings are
unaffected, which is what pointed at contention inside the test process
rather than decompiler cost.
Assisted-by: Claude:claude-fable-5:Claude Code
Hit testing for synthesized input is answered from the rendered scene, not from
the visual tree, and Dispatcher.UIThread.RunJobs() does not render one. The
context-menu gesture helpers pumped dispatcher jobs alone, so after Escape closed
a menu the next right-click could still be routed to the light-dismiss overlay of
the frame that was on screen: no ContextRequested was raised, no row became the
context target, and the assertion two lines later reported an unhighlighted row.
The macOS CI runner lost that race roughly once in forty gestures; a probe build
repeating the gesture caught a right-click that produced neither a pointer-over
nor a menu, and the fix survived 120 gestures on the same runner.
Avalonia's own headless input helpers pump the dispatcher and the render timer
together for this reason.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
There's an additional local variable when decompiling the non-optimized code; and explicitly putting that variable
into the test case just makes it fail due to yet another additional variable.
They were split out only because they were failing; there is no reason to keep
a second fixture now that they pass. Folding them in also widens their coverage
from roslyn4OrNewer to every defaultOptions config -- legacy csc, Roslyn 1.3.2
onwards and the net40 targets -- with the 'in'-receiver extension gated on CS72
because that one needs C# 7.2. IAwaitable and ClassAwaitable were declared
identically in both files and collapse into one declaration.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
The fixture was written as a spec of nine await shapes that decompiled to code
that does not compile. Six no longer do. Of the rest, default(Task) was never a
defect -- it compiles to the same ldnull as (Task)null, so the two are
indistinguishable in IL and the cast is a correct decompilation. The three real
ones are unrelated to the await conversion and have no correct output to pin
yet, so they move to #4017, #4018 and #4019; what stays behind is a regression
test for the shapes where the cast in front of the operand is load-bearing.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
An operand boxed for the GetAwaiter call is typed 'object', so the member
lookup that decides whether the await needs a cast finds nothing and a
redundant cast to the receiver type reaches the output. C# inserts that boxing
conversion implicitly, so the box may be dropped -- but only after the lookup
confirms the unboxed operand still binds the same GetAwaiter, and only via the
resolve result: UnwrapChild detaches the operand from the AST, so running it
speculatively leaves a cast with no child behind and decompilation of the whole
method falls back to the raw state machine.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
The await surface had almost no fixture coverage beyond Task/ValueTask: every
GetAwaiter in the corpus was an instance method on the awaited type itself, so
the conversion VisitAwait applies to the operand was never exercised for an
inherited, interface-typed or extension-method awaiter. Probing that surface
turned up eight defects, all of which produce C# that does not compile.
AsyncAwaitPatterns pins the shapes that do round-trip, along the three axes the
translation actually depends on: the GetAwaiter receiver, the operand
expression, and the context the await sits in. Its Correctness twin pins what
Pretty cannot see - copy semantics of struct awaitables and the evaluation
order around the suspension point.
AsyncAwaitPatternsBugs is the spec for the defects, written as the C# that
ought to come out, with the current wrong output named per member. It fails
today; that is the point, and fixing a defect is meant to delete a comment
rather than edit an expectation.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
The registry's summary still described the static accessor as resolving
it once, which stopped being true when the accessors began going through
the current composition host on every access.
Assisted-by: Claude:claude-fable-5:Claude Code
The app-level NativeMenu is process-wide, so the withdrawal a window does
on Closed has to name the items that window put there. Withdrawing
"whatever is promoted right now" is correct only while one window exists
at a time: with two, closing the older one takes the newer one's About /
Check for Updates out of the macOS app menu, and nothing ever puts them
back. Not reachable today - MainWindow is [Shared] and Attach runs from
its ctor - but the failure mode is silent and permanent, and carrying the
list costs nothing. Removing an item that is already gone is a no-op, so
a superseded window's Closed stays harmless.
The promotion tests also have to leave the app menu as they found it:
it is declared on Application and outlives the test, it is not gated on
macOS, and on Windows and Linux nothing re-promotes over the leftovers.
Assisted-by: Claude:claude-opus-5:Claude Code
ProgressBar.IsIndeterminate defaults to false, so the "nothing is running
yet" assertion would also pass against a pane whose DataContext is not
the resolved SearchPaneModel, and the failure would only surface one
line later, blamed on the binding direction rather than on the missing
DataContext.
Assisted-by: Claude:claude-fable-5:Claude Code
The app-level NativeMenu declared in App.axaml lives as long as the
process, while every MainWindow builds its own Help items over its own
command instances (AboutCommand reaches the DockWorkspace and, through
it, the whole app graph). PromoteHelpToMacAppMenu inserted each window's
items without taking the previous window's out and nothing removed them
on close, so on macOS the headless suite kept every test's app graph
alive - the same 13 MB per test as the anchors fixed earlier on this
branch, and the reason the memory win did not reproduce on macOS
(retained gen2 still climbing to ~4 GB there while a Windows run peaks
at 0.7 GB). Forcing the macOS path on Windows reproduces the growth
(14.3 GB peak private bytes over the suite); withdrawn, it is 0.7 GB.
Three smaller anchors of the same kind, found while making the canary
below hold in the full suite: RichNodeText and AnalyzerTreeNode cached
the first container's exports in statics, which subscribed later
windows to a stale settings object, handed later analyzers the first
test's assembly list, and kept the first app graph reachable for the
run; and a search still in flight when its container went away kept its
drain timer and IsSearching - hence the pane's indeterminate progress
animation on the render clock - alive, retaining every window a search
test closed mid-run (about 30 of them, ~400 MB).
The canary test closes a MainWindow the way the per-test teardown does
and waits for it to become collectable. It fails on any single anchor
being restored (checked by leaving DetachFlyouts out), which is the
regression guard the individual anchor fixes lacked; the teardown body
is exposed as TearDownTestState so the test performs exactly what
AfterTest does.
Assisted-by: Claude:claude-fable-5:Claude Code
Siegfried Pammer
Christoph Wille
dependabot[bot]
Daniel Grunwald