ILSpy

9645 Commits

54 Branches

94 Tags

91 MiB

Branch: fix/lambda-parameter-syntax

Commit Graph

Author	SHA1	Message	Date
ds5678	c40c299ff8	Read the full namespace path off tree namespace nodes, not the label In nested-namespace mode a NamespaceTreeNode's display label is only its last segment ("Generic"), while the full dotted path ("System.Collections.Generic") is what identifies the namespace in metadata and to the docs site. Three call sites read the label where they need the full path, so in nested mode each targets the wrong namespace: decompiling a namespace node queries an empty one and titles the output after the last segment; the MSDN URL points at the wrong page; and scope-search-to-namespace scopes to the wrong name. These are ds5678's fixes from #3879, reintegrated on top of the eager namespace rebuild. #3879's other Name -> FullName corrections, in AssemblyTreeNode.FindNamespaceNode and TreeNodeLocator, are already covered here by the full-namespace-name and type-handle indexes, so only the Decompile and search-entry cases carry over. Assisted-by: Claude:claude-opus-4-8:Claude Code	2 months ago
Siegfried Pammer	640b968b59	Rebuild the assembly-tree namespaces eagerly, as the WPF host did With "Use nested namespace structure" enabled, most namespaces never appeared in the tree, and the first expand of a large assembly lagged. Both come from the same regression: the Avalonia assembly-tree nodes were written from scratch as lazy scaffolding, not ported from the WPF design, and lost the single eager build the WPF host used. A NamespaceTreeNode filters as Recurse/MatchAndRecurse, so the filter cascade computes its IsHidden as "all children hidden" -- vacuously true for an empty child set. The lazy build attached each namespace node while it was still empty, latching intermediate namespaces (those that hold only sub-namespaces, e.g. System.Collections) hidden and stranding everything beneath them. The cascade also force-loads every namespace node's children anyway, so the per-node laziness avoided no work: it rescanned the whole TypeDefinitions table once per namespace node. Restore release/10.1's structure: AssemblyTreeNode builds the entire namespace band in one pass over the module's top-level types, populates each node before attaching it, and keeps two indexes -- full namespace name -> node and type handle -> node -- so FindNamespaceNode/FindTypeNode are O(1) and correct at any nesting depth. TreeNodeLocator.FindTypeNode (hyperlink clicks, search activation, JumpToType) delegates to that index instead of walking children by display name, which never matched in nested mode. NamespaceTreeNode goes back to a dumb label holder and re-escapes its display label via ILAmbience.EscapeName. The band is built from the module's type system, like 10.1's, not from raw metadata: each TypeTreeNode holds the resolved ITypeDefinition it renders from, so painting a cell no longer re-enters the settings-keyed type-system cache the way master's lazy node did on every Text/Icon/ Filter read -- each of which rebuilt an effective-settings object and took its lock. Ordering the pass by full ReflectionName is also what interleaves a namespace's types and its sub-namespaces into one alphabetical run (a sub-namespace attaches when its first descendant type is reached, landing at its own alphabetical slot among the sibling types); grouping all types ahead of all namespaces was a visible departure from the WPF order. Two deliberate departures from a literal 10.1 copy: keep the global- namespace "-" node, and keep the cached IsPublicAPI getter. Both index dictionaries are cleared on rebuild so a nested/flat toggle leaves no stale entries. Holding resolved entities means the tree has to be rebuilt when a setting changes the type system. Only one compilation is cached per module, keyed on the effective decompiler settings, so a language- version or decompiler-option change drops it and would otherwise leave every node pointing at a discarded compilation -- stale labels, icons and filters, and the C# 14 extension-block nodes shown against the wrong version. AssemblyTreeModel reloads the loaded assemblies when the computed TypeSystemOptions actually change (Display-only settings never do, and cost nothing), then restores the selected node from its path -- which re-expands its ancestors on the way to revealing it -- the way Refresh does. The WPF host got this for free: its modal Options dialog rebuilt the tree on close, where the Avalonia page applies live. Assisted-by: Claude:claude-opus-4-8:Claude Code	2 months ago

Author

SHA1

Message

Date

ds5678

c40c299ff8

Read the full namespace path off tree namespace nodes, not the label

In nested-namespace mode a NamespaceTreeNode's display label is only its
last segment ("Generic"), while the full dotted path
("System.Collections.Generic") is what identifies the namespace in
metadata and to the docs site. Three call sites read the label where they
need the full path, so in nested mode each targets the wrong namespace:
decompiling a namespace node queries an empty one and titles the output
after the last segment; the MSDN URL points at the wrong page; and
scope-search-to-namespace scopes to the wrong name.

These are ds5678's fixes from #3879, reintegrated on top of the eager
namespace rebuild. #3879's other Name -> FullName corrections, in
AssemblyTreeNode.FindNamespaceNode and TreeNodeLocator, are already
covered here by the full-namespace-name and type-handle indexes, so only
the Decompile and search-entry cases carry over.

Assisted-by: Claude:claude-opus-4-8:Claude Code

2 months ago

Siegfried Pammer

640b968b59

Rebuild the assembly-tree namespaces eagerly, as the WPF host did

With "Use nested namespace structure" enabled, most namespaces never
appeared in the tree, and the first expand of a large assembly lagged.
Both come from the same regression: the Avalonia assembly-tree nodes
were written from scratch as lazy scaffolding, not ported from the WPF
design, and lost the single eager build the WPF host used.

A NamespaceTreeNode filters as Recurse/MatchAndRecurse, so the filter
cascade computes its IsHidden as "all children hidden" -- vacuously true
for an empty child set. The lazy build attached each namespace node
while it was still empty, latching intermediate namespaces (those that
hold only sub-namespaces, e.g. System.Collections) hidden and stranding
everything beneath them. The cascade also force-loads every namespace
node's children anyway, so the per-node laziness avoided no work: it
rescanned the whole TypeDefinitions table once per namespace node.

Restore release/10.1's structure: AssemblyTreeNode builds the entire
namespace band in one pass over the module's top-level types, populates
each node before attaching it, and keeps two indexes -- full namespace
name -> node and type handle -> node -- so FindNamespaceNode/FindTypeNode
are O(1) and correct at any nesting depth. TreeNodeLocator.FindTypeNode
(hyperlink clicks, search activation, JumpToType) delegates to that
index instead of walking children by display name, which never matched
in nested mode. NamespaceTreeNode goes back to a dumb label holder and
re-escapes its display label via ILAmbience.EscapeName.

The band is built from the module's type system, like 10.1's, not from
raw metadata: each TypeTreeNode holds the resolved ITypeDefinition it
renders from, so painting a cell no longer re-enters the settings-keyed
type-system cache the way master's lazy node did on every Text/Icon/
Filter read -- each of which rebuilt an effective-settings object and
took its lock. Ordering the pass by full ReflectionName is also what
interleaves a namespace's types and its sub-namespaces into one
alphabetical run (a sub-namespace attaches when its first descendant
type is reached, landing at its own alphabetical slot among the sibling
types); grouping all types ahead of all namespaces was a visible
departure from the WPF order.

Two deliberate departures from a literal 10.1 copy: keep the global-
namespace "-" node, and keep the cached IsPublicAPI getter. Both index
dictionaries are cleared on rebuild so a nested/flat toggle leaves no
stale entries.

Holding resolved entities means the tree has to be rebuilt when a
setting changes the type system. Only one compilation is cached per
module, keyed on the effective decompiler settings, so a language-
version or decompiler-option change drops it and would otherwise leave
every node pointing at a discarded compilation -- stale labels, icons
and filters, and the C# 14 extension-block nodes shown against the wrong
version. AssemblyTreeModel reloads the loaded assemblies when the
computed TypeSystemOptions actually change (Display-only settings never
do, and cost nothing), then restores the selected node from its path --
which re-expands its ancestors on the way to revealing it -- the way
Refresh does. The WPF host got this for free: its modal Options dialog
rebuilt the tree on close, where the Avalonia page applies live.

Assisted-by: Claude:claude-opus-4-8:Claude Code

2 months ago

2 Commits (fix/lambda-parameter-syntax)