ILSpy

9745 Commits

54 Branches

94 Tags

91 MiB

Tree: fa464968e1

Commit Graph

Author	SHA1	Message	Date
Siegfried Pammer	b2b82ce6a8	Stream the search's assembly walk instead of materializing it 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	1 month ago
Siegfried Pammer	ba7fe1d75f	Share the settings-derived type system between tree, search, and views LoadedAssembly caches one type system per TypeSystemOptions value, but the consumers disagreed on which one to use: tree nodes and the metadata navigator resolved through GetTypeSystemOrNull (a separate default-options instance) and the search built its request with default settings. Each module could therefore materialise several type systems, and none of the display surfaces respected settings that change entity shapes (nullability, tuples, extension methods, ...). WPF routed all of these through GetTypeSystemWithCurrentOptionsOrNull. Reintroduce that helper on top of CreateEffectiveDecompilerSettings and use it in TypeTreeNode, AssemblyReferenceTreeNode, and the metadata navigator; the search request now derives its settings the same way, so all of them hit the same cached instance. NamespaceTreeNode.Decompile enumerates through the type system matching the decompilation options it was handed. Assisted-by: Claude:claude-fable-5:Claude Code	3 months ago

Author

SHA1

Message

Date

Siegfried Pammer

b2b82ce6a8

Stream the search's assembly walk instead of materializing it

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

1 month ago

Siegfried Pammer

ba7fe1d75f

Share the settings-derived type system between tree, search, and views

LoadedAssembly caches one type system per TypeSystemOptions value, but
the consumers disagreed on which one to use: tree nodes and the
metadata navigator resolved through GetTypeSystemOrNull (a separate
default-options instance) and the search built its request with default
settings. Each module could therefore materialise several type systems,
and none of the display surfaces respected settings that change entity
shapes (nullability, tuples, extension methods, ...). WPF routed all of
these through GetTypeSystemWithCurrentOptionsOrNull.

Reintroduce that helper on top of CreateEffectiveDecompilerSettings and
use it in TypeTreeNode, AssemblyReferenceTreeNode, and the metadata
navigator; the search request now derives its settings the same way, so
all of them hit the same cached instance. NamespaceTreeNode.Decompile
enumerates through the type system matching the decompilation options
it was handed.

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

3 months ago

2 Commits (fa464968e1bb7ab84939d31d4dcd73eff3f44588)