ILSpy

9123 Commits

25 Branches

90 Tags

71 MiB

Tree: aab6303870

Commit Graph

Author	SHA1	Message	Date
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 weeks ago

Author

SHA1

Message

Date

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 weeks ago

1 Commits (aab6303870dbd439a5c9368287c5dd97860a2580)