ILSpy

9743 Commits

54 Branches

94 Tags

91 MiB

Tree: 91e9592353

Commit Graph

Author	SHA1	Message	Date
Siegfried Pammer	0566a81510	Make the ILAst dump faithful to what the decompiler runs The dump is only useful if it shows the same thing the real pipeline is fed and covers everything a transform bug can hide in, so: accessor bodies are reached through the metadata handles (ITypeDefinition.Methods hides every method that has method semantics), the PDB reaches the ILReader (UseDebugSymbols alone is inert without DebugInfo), and the writing options carry the same sugar as the UI's ILAst pane. A method whose body cannot be read, transformed or written no longer aborts the run, and the failure now travels through the decompilation-error path, so a crashing transform is visible in stderr and in the exit code instead of being buried in the output a script just collected. BlockILTransform entries name the transforms they contain: two of them ran as identical rows before, and asking for a nested transform by name reported it as unknown while the listing did in fact run it. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	1 month ago
Siegfried Pammer	259c843483	Add ILAst output to ilspycmd debug builds The decompiler's intermediate representation was reachable only through the GUI's ILAst language, so anyone debugging a transform or a matcher had to do it by hand in the UI. --ilast writes the same representation to stdout, and --after-transform truncates the pipeline at a chosen point, which makes the effect of a single transform diffable and scriptable. Debug-only, like the UI language it mirrors: ILAst serves ILSpy's own development, not the users of the released tool, so it stays out of the shipped NuGet package and out of the README's option list. Nested per-block transforms stay unaddressable: they run inside a BlockILTransform entry, and reaching them needs the Stepper, which is compiled out of release builds anyway. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	1 month ago

Author

SHA1

Message

Date

Siegfried Pammer

0566a81510

Make the ILAst dump faithful to what the decompiler runs

The dump is only useful if it shows the same thing the real pipeline is fed and
covers everything a transform bug can hide in, so: accessor bodies are reached
through the metadata handles (ITypeDefinition.Methods hides every method that
has method semantics), the PDB reaches the ILReader (UseDebugSymbols alone is
inert without DebugInfo), and the writing options carry the same sugar as the
UI's ILAst pane.

A method whose body cannot be read, transformed or written no longer aborts the
run, and the failure now travels through the decompilation-error path, so a
crashing transform is visible in stderr and in the exit code instead of being
buried in the output a script just collected.

BlockILTransform entries name the transforms they contain: two of them ran as
identical rows before, and asking for a nested transform by name reported it as
unknown while the listing did in fact run it.

Assisted-by: Claude:claude-opus-5[1m]:Claude Code

1 month ago

Siegfried Pammer

259c843483

Add ILAst output to ilspycmd debug builds

The decompiler's intermediate representation was reachable only through the
GUI's ILAst language, so anyone debugging a transform or a matcher had to do it
by hand in the UI. --ilast writes the same representation to stdout, and
--after-transform truncates the pipeline at a chosen point, which makes the
effect of a single transform diffable and scriptable.

Debug-only, like the UI language it mirrors: ILAst serves ILSpy's own
development, not the users of the released tool, so it stays out of the shipped
NuGet package and out of the README's option list.

Nested per-block transforms stay unaddressable: they run inside a
BlockILTransform entry, and reaching them needs the Stepper, which is compiled
out of release builds anyway.

Assisted-by: Claude:claude-opus-5[1m]:Claude Code

1 month ago

2 Commits (91e9592353d908adf5e9b3bcdfaff53fc65b5aa2)