ILSpy

9330 Commits

54 Branches

94 Tags

91 MiB

Branch: tests/829-list-patterns

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

1 Commits (tests/829-list-patterns)