The file this branch adds takes the contributor's name rather than
AlphaSierraPapa, and three comments it added drop their en-GB spelling.
EndOpenGroups now requires its target depth: zero is the one value that closes
groups the caller does not own, which is the misattribution the depth argument
was added to prevent.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Three copies of the same pre-order walk across two test files become
TreeTraversal.PreOrder, and the stepper fixture builds its decompiler through
the file-name constructor instead of assembling the type system by hand.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Two things about the step tree's presentation. Nothing said which half of the
pipeline a step belonged to, so each one now names its phase from what it points
at - instructions for the IL half, syntax nodes for the C# half - and a group
opener with no anchor takes it from the first step underneath.
And the wrappers are built on demand because a recorded type runs to tens of
thousands of steps, but the filter walked them and so built every one on the
first keystroke. It now asks the recorded steps whether a subtree contains a
match, and only descends into wrappers that already exist or are on a revealed
path.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
The recorded steps are pinned on the MEF-shared C# language, but the release
went through the pane's attached language, which is null whenever another
language is selected - open the pane on C#, switch to IL, close it, and the tree
stayed alive until the next full C# run. The language still raises StepperUpdated
at the end of every run, so a run that outlived the pane pinned its tree straight
back in. And opening the pane re-ran the decompile whatever the language,
discarding the view for a tree that only C# can produce.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Recording only gated the IL half, so a run with it off still numbered the C# AST
transforms into the shared stepper. That gave one pipeline two numbering scales,
and a step index is only meaningful against the scale it was recorded on: a tree
captured under one and replayed under the other selects a different step. It
also let the crashed-member attribution fire on a counter that had never moved -
a limit of zero matched at every throwing transform and rendered an unrelated
member's ILAst.
The flag now gates both halves, so steps exist exactly when recording is on, and
it lives on the pane instance rather than a static the background decompile read
across threads.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
The pane used to split the pipeline across two languages: the ILAst language
stepped the IL transforms, the C# language stepped the AST transforms, and
nothing showed the seam between them, so a step index meant a different thing
depending on which language happened to be selected. Recording both halves into
one Stepper makes an index replayable across the whole pipeline; a limit that
lands in the IL phase has no C# to print, so the halted function is rendered as
ILAst instead.
Which function that is takes some care, because a member group's EndStep is the
next member's first step: a halt standing on a member's opening step belongs to
the member that just finished, a transform that throws where the limit was aimed
has to hand over the ILAst it half-transformed (what the ILAst language showed
as "ILAst after the crash"), and a step recorded on a helper function the
pipeline has not attached yet belongs to that function's own tree.
Retention stays opt-in twice over: the decompiler records IL steps only when
asked to, and the pane asks only while its view is on screen. Every kept step
pins the ILAst it captured, which for one type runs to tens of thousands of
nodes, so a closed pane would be paying for a tree nobody displays.
What is left of the ILAst language is its typed-IL dump, which runs no
transforms at all. That stays, as TypedILLanguage. IDebugStepProvider was down
to a single implementation and is removed.
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
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
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 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
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
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
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
The search pane's progress bar was permanently indeterminate and merely
hidden when idle, and the decompiler view's bar defaults to
indeterminate mode whether or not a decompilation is running. The
indeterminate indicator is an infinite keyframe animation that keeps
running - and keeps the control's whole visual tree alive through the
render clock - for as long as the pseudo-class is set, hidden or not.
Both bars now go indeterminate only for the duration of the work.
Assisted-by: Claude:claude-fable-5:Claude Code
The headless test host runs the app without an application lifetime,
so the window-closing step in ResetAppState never had a list to work
from and every MainWindow the suite showed stayed open - and reachable
from the compositor, together with its view-models, assembly tree and
loaded assemblies. Measured at about 13 MB per test, 15 GB over the
suite, enough to page out the CI runner and stall the tests that scan
process module lists.
Closing is not sufficient on its own: Avalonia's Button subscribes to
its flyout's Opened/Closed and only unsubscribes when the Flyout
property changes, and Dock's ToolChromeControl theme hands every tool
pane's chrome button one shared MenuFlyout resource, which therefore
pinned every closed window's visual tree. The flyouts are detached
before the window closes.
Assisted-by: Claude:claude-fable-5:Claude Code
Resolving a metadata file to its assembly node learned to descend into packages,
but three sibling lookups kept their own scan of the root's direct children, so
a token reference, a metadata:// link and a LoadedAssembly reference still
resolved to nothing inside a package. One of them sat behind a guard whose
result was never used, which returned early for exactly the case it was meant to
serve. Routing all of them through the one lookup fixes them together.
Namespaces were matched by comparing a full name against a node label, which is
only ever equal in flat mode: with nested namespace nodes the label is the last
segment, and the empty-name test matched the first child rather than the global
namespace node. The assembly node already indexes its namespaces by full name.
The descent itself no longer sweeps the package depth-first. Expanding a folder
resolves and extracts every .dll it holds, so the path is taken from the
package's folder graph, which costs no tree node and reads no entry.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Searching a package resolves its entries by file name against a case-insensitive
cache, which is right for an assembly reference but wrong for an archive entry:
two entries differing only in case are two files, and they collapsed onto one
LoadedAssembly, so one was searched twice and the other never. Keying the cache
by the entry itself separates them, and the entry's package-relative path
becomes the assembly's file name, which is what tells the copies of one assembly
in a multi-target package apart wherever a search result shows a location.
Cancellation was only checked between top-level list entries, so a walk the user
had already replaced by typing another character kept extracting package entries
alongside the run they were waiting for. The omnibar had no way to end its run at
all: its view model is per document tab and nothing cancelled it when the tab
went away.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Resolving a type to its tree node scanned every descendant of the root, which
means every namespace node of every assembly - all of them built eagerly - to
find the one assembly node it needed. A package child records the bundle it
came from, so that chain leads straight to the single top-level node worth
descending into, and only that package's folders are searched from there.
The two sibling lookups only ever considered the root's direct children, so
neither resolved anything inside a package at all. Sharing one helper fixes
them along the way, and it expands package folders on the descent because
search surfaces package contents whether or not the tree was ever opened
there.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Searching inside bundles and packages means expanding them, and the expansion
has to await each assembly's load result - which is what triggers the lazy
load in the first place. Building the full list up front (as the WPF pane did)
therefore means a search on a freshly restored list produces nothing at all
until the last assembly is off disk, and the blocking wait for it ignored the
cancellation token the pane fires on every keystroke.
The snapshot is still taken eagerly, before the first element is yielded, so
the set cannot change under a running walk; a failing assembly or an
unreadable package entry skips itself rather than abandoning the rest.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
The rich hover popup hardcoded a near-white background and border while
its signature text is coloured by the active highlighting theme, so in
dark mode light-on-dark syntax colours landed on a light box and were
unreadable. The chrome and the doc-link colour now route through
theme-variant brushes; light mode keeps the established near-white look.
Assisted-by: Claude:claude-fable-5:Claude Code
NativeMenuItem.Gesture is display-only when NativeMenuBar renders the
menu inline on Windows/Linux: the managed fallback binds it to
MenuItem.InputGesture, which never handles input. Only macOS's system
menu bar actually executes its key equivalents, so Ctrl+O, Ctrl+S and
F5 showed in the menu but did nothing. The Avalonia docs call this out
explicitly: InputGesture only displays the text and must be paired with
a KeyBinding for the shortcut to function.
Assisted-by: Claude:claude-fable-5:Claude Code
The dark palette is hand-authored for C# only; every other highlighting
definition -- XML, IL, Asm, and all AvaloniaEdit built-ins -- is derived by
inverting HSL lightness. HSL lightness is not perceptual luminance, so the
result depended entirely on hue: blue carries a 0.0722 luminance weight, so
plain Blue landed at 4.08:1 against the editor canvas, and an already-light
source such as Asm's #8080FF inverted downwards to 1.29:1 -- invisible.
Reported against XML resources in #3986.
Enforcing a 5.5:1 WCAG floor on the converted foreground fixes every affected
definition in the one place they all route through, which a per-language
palette would not: the AvaloniaEdit built-ins (JSON, Markdown, JS, HTML, CSS,
Python) have no palette to author. 5.5 is where the existing CSharpDark values
already sit; the 4.5 AA threshold was measured and only moves the reported blue
to 4.51. The floor is deliberately foreground-only -- forcing a span background
to contrast with the canvas would repaint Asm's #EEEEEE Registers background as
a bright block and bury the text on top of it -- and it is measured against the
surface the foreground lands on, which is that span background when the colour
declares one, so a light-on-dark span cannot be pulled apart into two colours
that no longer contrast with each other.
The same function's desaturation guard only fired when the inverted lightness
stayed below 0.75, so a dark fully saturated source (DarkMagenta) came back
light and still fully saturated -- exactly the neon the softening exists to
prevent. Only the softening becomes unconditional; the lightness lift paired
with it stays scoped to over-saturated colours, because it is not monotone
across its own 0.75 boundary and would reorder neighbouring greys.
Hyperlinks were a second, unrelated path: nothing ever set
TextView.LinkTextForegroundBrush, so the About page and every decompiler-view
link used AvaloniaEdit's registered default of pure blue, 1.94:1 on dark. They
now share a themed ILSpy.LinkForeground with the metadata table's token cells,
which take it from a style rather than a local Foreground so the selected row's
white override still wins over the accent fill.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Middle_Click_On_An_Assembly_Tree_Row_Opens_A_New_Decompiler_Tab timed out
after its full 60s window on the macOS CI runner. The tests picked the first
SharpTreeViewItem present in the visual tree and clicked its centre, but a
container realised by the virtualizing panel is not necessarily arranged yet,
and a row can sit outside the grid's viewport - on a loaded runner, where
assemblies are still streaming into the tree, the click landed on nothing and
the gesture never happened. The two negative tests shared the same click-point
computation and would have passed vacuously in that state, so a missed click
was only ever visible on the positive one.
Hit-testing the candidate point back to its own row before clicking rules both
out, and fails with a description instead of an unexplained timeout if no row
is ever reachable.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Review follow-ups on #3998: reject non-finite parses (NaN slips through
Math.Clamp and, once persisted, permanently fails the editor's
SelectedFontSize > 0 guard), commit the clamped value back into the box on
focus loss (the echo suppression otherwise leaves a typed "3" on screen while
6 pt is stored), and assert the theme actually realizes PART_EditableTextBox
instead of trusting the IsEditable property. The 4/3 pt/px ratio is documented
as the WPF-host convention it is - exact on Windows/X11, deliberately not the
Cocoa-point number on macOS - rather than a universal.
Assisted-by: Claude:claude-fable-5:Claude Code
The options dialog bound DisplaySettings.SelectedFontSize (device-independent
pixels) straight into a NumericUpDown, so a fresh profile showed 13.33 and the
6-72 bounds were pixels. The WPF host presented points via FontSizeConverter;
this restores that behavior on Avalonia with an editable size ComboBox (like
the Windows font dialogs) backed by a pt/px proxy on the viewmodel. The stored
value stays pixels so settings files keep round-tripping with ILSpy 9.x.
Assisted-by: Claude:claude-fable-5:Claude Code
Review of #3989 pointed out that guarding registration on the theme-aware
marker conflates "XSHD opts out", "already themed" and "already registered",
and leans on two non-contractual AvaloniaEdit details (the delay-load
wrapper's Properties forwarding and its materialize-on-touch behaviour).
Keying the pristine-colour snapshots by colour instance (ConditionalWeakTable)
instead of by definition makes the in-place theming idempotent no matter how
many definition identities expose the colours, so correctness no longer
depends on registration order or the marker; the guard remains only to honour
the XSHD opt-out and to skip redundant list entries. ApplyHighlightingColors
is now private so nothing can set the marker outside a registration.
Also from review: the new tests move to a uniquely named fixture (the old
name collided with Themes/ThemeAwareHighlightingColorizerTests), gain
coverage of the Light/Dark switch path after a dark startup, and the cache
characterization asserts the reconverted content instead of relying on inert
theme switches.
Assisted-by: Claude:claude-fable-5:Claude Code
With dark preselected, the first document of a session rendered with a
double-converted (washed-out) palette; resources showed it across every
token, C# only on tokens outside the hand-authored dark palette. The
same definition was registered with the theme manager under two
identities: HighlightingManager hands out a delay-loaded wrapper whose
members forward to the inner definition that HighlightingService.Load
registers during materialization. Registering the wrapper afterwards
snapshotted the shared colours AFTER the inner registration had already
darkened them, so the snapshot's "light originals" were dark values and
the rewrite darkened them a second time. In-session theme switches were
unaffected because the first touch happens in Light, where both
snapshots are pristine -- which is why the bug only appeared when dark
was already active at first touch.
Skip registration when the definition is already theme-aware: reading
the marker forces the wrapper to materialize, so the check observes the
inner registration. This also stops the remap from clobbering
definitions whose XSHD opts out via ILSpy.IsThemeAware.
Assisted-by: Claude:claude-fable-5:Claude Code
ThemeManager and ThemeAwareHighlightingColorizer split dark mode between
them: the manager darkens a registered definition's named colours in
place, the colorizer per-paint-remaps colours of unregistered
definitions. Running both on one definition converts every colour twice
and washes the palette out. The colorizer captured IsThemeAware once in
its constructor, so a definition registered after the colorizer was
created would be double-converted from then on. Today every colorizer
is created after registration (HighlightingService registers inside
GetByExtension/Load before returning), but that is a calling
convention, not an invariant; reading the flag per paint removes the
ordering dependency.
The colorizer's dark-conversion cache needs no matching flush: its keys
use HighlightingColor's content-based equality, so recolouring a source
colour in place changes its hash and the lookup misses instead of
serving a conversion of the old values. A characterization test pins
that, so an equality-semantics change in AvaloniaEdit shows up as a red
test rather than as stale colours.
Assisted-by: Claude:claude-fable-5:Claude Code
These explain the code by pointing at the front-end that used to implement it.
That front-end is no longer in the tree, so the referent a reader would go
looking for does not exist: "Mirrors WPF's RefreshDecompiledView() call" names
a method nobody can open. In almost every case the sentence beside it already
carried the reason, and the reference was an appendix.
Comments citing a live platform difference are left alone, because there the
comparison is the reason rather than a memory: Avalonia genuinely has no
global RequerySuggested signal, which is why SimpleCommand exists at all.
One had gone stale rather than merely redundant. DerivedTypesEntryNode
described consulting the active search term as a missing feature to reinstate,
but SearchTermMatches is deliberately a no-op so the assembly tree stays
independent of the search pane; the comment now says so.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
A comment that justifies behaviour by pointing at the WPF front-end means
nothing to someone reading the file cold: the reason is either already stated
beside it or is not stated anywhere. Each of these now names the constraint
itself - why navigation waits for pointer-release, why a signature block wraps,
why the tree filter ignores the search term.
Comments citing an external product's documented behaviour as the source of a
rule are left alone; there the reference is the reason, not a memory of how the
code arrived.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Zoom was stored as the font size itself, so the zoom overlay had no way to
tell a Ctrl+Wheel zoom from a font size picked in the options dialog: any
size other than the hard-coded default made the overlay appear, and the
percentage was measured against that default rather than the user's font.
A separate multiplier restores the split the setting always implied - the
options dialog moves the base size, zoom scales it - so 100% means "the
font you configured", whatever that is.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
Five fixtures covered the "Use nested namespace structure" setting, four of
them running the same toggle at a different layer: the model shape, the same
toggle awaited live, and the same toggle again asserting it reached the
SharpTreeView's rows. Each paid its own boot for a scenario that is one story
end to end, and together they were the second-largest block of time in the
suite after the process-list scroll loops. One test now walks the whole path
once, carrying every assertion the four had, including the nesting depth only
the first checked.
The comparison view's model-is-bound test is dropped: the test after it
renders rows out of that model, which cannot happen unless it is bound, and
it opened two fixture assemblies to prove it.
The expander hitbox test asserted the toggle measures 13x16 and its glyph 9x9,
then clicked 14px down to prove the area below the glyph is live. The click
proves the geometry; the measurements only restate it, and would fail on a
font-metric change that broke nothing. Its layout-settling loop slept 200ms
unconditionally, which is a race that usually wins - it now waits for the
condition it needs.
Assisted-by: Claude:claude-opus-5:Claude Code
These fixtures were written while porting to Avalonia, as an author's own
verification step rather than as coverage: reflection asserting that a type
derives from its base and that a property has the type it is declared with;
literals (MinHeight 29, Padding 3, MaxWidth 900) copied out of the .axaml
beside them; a property override asserted only so pane descendants stay
reachable from tests. None of them can fail except when someone deliberately
edits the line they mirror, and then they fail as a chore.
StartupPerfTests keeps its two [Explicit] benchmarks, which print per-phase
timings worth reading. The third was a wall-clock assertion (8 CoreLib copies
must settle in under 15s) that ran in CI, where a shared runner decides the
verdict; as [Explicit] it would be strictly dominated by the 200-assembly
benchmark it was derived from, so it goes.
Two fixtures are trimmed rather than deleted, because their kernel is real:
XmlDocLoader's ref-pack fallback has no other test in the repo, and the
MenuIcon metadata rasterisation was dropped once during the port already.
Both now assert that without booting MainWindow to reach it.
This is worth about two seconds - it buys reviewers less to read, not CI
less to do.
Assisted-by: Claude:claude-opus-5:Claude Code
* Set v11 RTM
* Update features in README.md
* Remove the two 900-iteration process-list scroll tests
* Keep Svg.Controls.Skia.Avalonia at 12.0.0.13
* 10.0.11 and Roslyn for net11p7
* Fix module-scan test failing when PowerShell's NGen images are stale
* Opt Pack NuGets out of the MSBuild server to fix SBOM generation
An export's ITextOutput goes nowhere: ProjectExporter and SolutionWriter both
hand the language a throwaway PlainTextOutput and build their own status
report, so a language writing failures into that output is invisible. The
failures travel on DecompilationOptions instead and are rendered by the caller
that owns the report - each one with its full exception in a collapsed fold,
which is what makes a bug report actionable.
Drive-by: WriteExceptionDetails split the exception text without trimming, so
for exceptions rendering a trailing newline the fold reached one line past the
last frame and swallowed the line behind it; and the tab's own decompilation-
failure path had regressed to dumping a raw stack trace instead of using that
helper.
Assisted-by: Claude:claude-opus-5[1m]:Claude Code
The bookmark navigation tests asserted the one-shot line highlight by
polling the text view's renderer collection, but the adorner
self-dismisses after an ~800 ms lifetime driven by a DispatcherTimer.
On a loaded CI runner (the desktop job runs the UI and decompiler test
suites concurrently) the dispatcher can stall long enough that the
adorner registers and is dismissed again before the test's next
predicate check, so the wait misses the entire play and burns its full
60 s timeout; raising the timeout cannot help with that. Record the
last played line on DecompilerTextView as persistent evidence of the
one-shot highlight and assert that instead - it also pins the highlight
to the expected line, which the presence check never did.
Assisted-by: Claude:claude-fable-5:Claude Code
The tab-opening test only verifies document tab and selection wiring. Using a tiny in-assembly fixture avoids cold framework decompilation work in CI and lowers the chance of unrelated timeout noise.
Assisted-by: OpenCode:openai/gpt-5.5:OpenCode
Right-clicking inside the details editor inherited the metadata grid's
cell-oriented context menu, whose Copy entries are enabled only for a
hovered DataGridCell -- inside the details area there is none, so the
menu showed permanently disabled entries and selected text could not be
copied by mouse. The editor now carries the decompiler view's editor
menu shape: Copy (rich HTML copy with plain fallback, enabled while a
selection exists) and Select All. Enablement is decided in
ContextMenu.Opening, which only the context-request gesture raises;
the test therefore raises ContextRequested instead of calling Open().
Assisted-by: Claude:claude-fable-5:Claude Code
A one-line payload (short hex dump, tiny source-link document) rendered
as a squeezed strip barely taller than the row itself, which does not
read as an expandable details area. Floor the editor at 100px so the
details region stays visually recognisable regardless of payload size.
Assisted-by: Claude:claude-fable-5:Claude Code
The text-blob editor in the metadata row-details area hardcoded its font
and lacked the text view's flat selection highlight, so embedded source
looked different from the decompiled code right next to it and ignored
the user's font choice in the Options page. The decompiler-view look
(user-selected font applied live while attached, themed background,
square-cornered translucent selection) now lives in DecompilerTextEditor
itself, giving every surface hosting the editor the same appearance by
construction; DecompilerTextView and BuildTextBlob drop their now
redundant per-site styling.
Assisted-by: Claude:claude-fable-5:Claude Code
The CustomDebugInformation details area rendered decoded text payloads
(embedded source, source-link JSON, hex dumps) in a plain TextBox, which
shows code without any highlighting and materializes the whole formatted
text up front, so large embedded-source documents were expensive. Text
payloads now travel as a TextBlobDetail tagged with a file extension --
".json" for source link, the parent document's extension for embedded
source, none for hex -- and render in the theme-aware AvaloniaEdit
editor, which colours them via the existing highlighting registry and
virtualizes long documents. The editor's ThemeChanged subscription moves
from the constructor to OnAttachedToVisualTree so it stays paired with
the detach-time unsubscribe now that editors can leave and re-enter the
visual tree inside recycled row-details containers.
Assisted-by: Claude:claude-fable-5:Claude Code
Siegfried Pammer
Christoph Wille