pimhwang/ILSpy - ILSpy - git.quantfans.net

Author	SHA1	Message	Date
Christoph Wille	84a7839a29	Withdraw a window's Help items from the macOS app menu, and add a retention canary 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	4 weeks ago
Christoph Wille	3b37eff5d3	Close every window a headless UI test showed, and let go of shared flyouts 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	4 weeks ago
Siegfried Pammer	f53ca6d080	Drop redundant global:: qualifiers on ICSharpCode references The global:: prefixes existed because the test project's namespace ICSharpCode.ILSpy.Tests used to shadow the app's old top-level ILSpy namespace. With the UI code back under ICSharpCode.ILSpy there is nothing left to shadow, so plain fully qualified names resolve fine. Assisted-by: Claude:claude-fable-5:Claude Code	3 months ago
Siegfried Pammer	51aafa0fd9	Move ILSpy UI code back to the ICSharpCode.ILSpy root namespace The Avalonia port had placed the UI app in an ILSpy.* namespace tree, while the csproj RootNamespace and every prior release (through 10.1) use ICSharpCode.ILSpy.*. Restoring the historical namespace reduces the public API diff against release/10.1 for plugin authors and removes the shadowing that forced global:: qualifiers in the test project. The Images class and AccessOverlayIcon enum move back into the root namespace (as in 10.1), since an ICSharpCode.ILSpy.Images namespace would shadow the Images class for all code inside ICSharpCode.ILSpy. Assisted-by: Claude:claude-fable-5:Claude Code	3 months ago
Siegfried Pammer	4d99dea6c5	Drive decompiles to quiescence between headless tests A test that triggers a decompile spawns a Task.Run plus dispatcher continuations and rarely awaits them; the per-test ResetAppState closed windows and drained the dispatcher but never cancelled the background work, so a continuation could land during the next test and read the swapped-in AppComposition.Current -- the dominant source of order-dependent flakiness (a different test tipped each run). Give DecompilerTabPageModel an internal CancelPendingAsync (store the in-flight decompile task, cancel its CTS, return it) and DockWorkspace a CancelPendingOperationsAsync that fans that across every document tab -- both legitimate shutdown hygiene too. ResetAppState.AfterTest now cancels and pumps the dispatcher until the work unwinds before the next test boots. This stops the random rotation of the failing test (the victims are now stable and diagnosable); two order-dependent failures remain (About-tab duplication and a nested-namespace tree race) that need their own fixes -- they still pass in isolation.	3 months ago
Siegfried Pammer	88da898d0c	MEF basics	3 months ago