ILSpy

9392 Commits

54 Branches

94 Tags

91 MiB

Tree: faee2e29e0

Commit Graph

Author	SHA1	Message	Date
Siegfried Pammer	a1726a9dbf	Fix #3938 : nested-type members must not inherit ExtensionInfo The .NET 10 BCL ships static [Extension] classes that contain ordinary nested types (e.g. XDocumentExtensions.XDocumentNavigable). Decompiling such a nested type's member in isolation resolved the enclosing container's ExtensionInfo, and DecompileBody then dereferenced the missing extension-member mapping. A container without any extension blocks now reports no ExtensionInfo at all, and ResolveExtensionInfo applies a container's info only to members that actually belong to one of its extension blocks. Assisted-by: Claude:claude-fable-5:Claude Code	2 months ago
Siegfried Pammer	a537dad7ef	Fix #3774 : keep field initializers when decompiling a static ctor alone The "IL with C#" view decompiles each method body as a bare handle, so a static constructor is decompiled without its type's field declarations in the syntax tree. MoveFieldInitializersToDeclarations then could not find a declaration to move the static-field-initializer statement onto, asserted (kind was Static, not Primary) and dropped the statement -- crashing Debug builds and silently losing the assignment in Release. Dropping the statement is only correct for the primary-constructor case, where the assignment's backing member is synthesized and has no separate declaration. For static/instance initializers a missing declaration just means the member is not part of this partial syntax tree, so the assignment must remain in the constructor body. Assisted-by: Claude:claude-opus-4-8:Claude Code	3 months ago

Author

SHA1

Message

Date

Siegfried Pammer

a1726a9dbf

Fix #3938 : nested-type members must not inherit ExtensionInfo

The .NET 10 BCL ships static [Extension] classes that contain ordinary
nested types (e.g. XDocumentExtensions.XDocumentNavigable). Decompiling
such a nested type's member in isolation resolved the enclosing
container's ExtensionInfo, and DecompileBody then dereferenced the
missing extension-member mapping. A container without any extension
blocks now reports no ExtensionInfo at all, and ResolveExtensionInfo
applies a container's info only to members that actually belong to one
of its extension blocks.

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

2 months ago

Siegfried Pammer

a537dad7ef

Fix #3774 : keep field initializers when decompiling a static ctor alone

The "IL with C#" view decompiles each method body as a bare handle, so a
static constructor is decompiled without its type's field declarations in
the syntax tree. MoveFieldInitializersToDeclarations then could not find a
declaration to move the static-field-initializer statement onto, asserted
(kind was Static, not Primary) and dropped the statement -- crashing Debug
builds and silently losing the assignment in Release.

Dropping the statement is only correct for the primary-constructor case,
where the assignment's backing member is synthesized and has no separate
declaration. For static/instance initializers a missing declaration just
means the member is not part of this partial syntax tree, so the
assignment must remain in the constructor body.

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

3 months ago

2 Commits (faee2e29e01578af5cd56ef0f31f3bc953df0503)