ILSpy

9330 Commits

54 Branches

94 Tags

91 MiB

Branch: tests/829-lambda-param-modifiers

Commit Graph

Author	SHA1	Message	Date
Siegfried Pammer	4c04e01882	Cover virtual, overloaded, and renamed-Implements parameterized properties The renamed-Implements case exposed a gap: the accessor-method declarations did not include the explicit-interface-implementation forwarders generated from .override directives, so decompiled types did not implement their interfaces and same-name implementations lost their interface mapping. DecompileParameterizedProperty now emits the same forwarder stubs as the ordinary method path. Assisted-by: Claude:claude-fable-5:Claude Code	2 months ago
Siegfried Pammer	832090c08d	Emit parameterized-property accessors as ordinary methods C# cannot declare a named property with parameters: only the type's default member gets indexer syntax, and reusing it via [IndexerName] collapses for types with several differently-named indexed properties, static properties, or explicit interface implementations. Emitting the accessors as ordinary methods is the only fully general compilable form, matches how C# consumes such properties (Roslyn exposes the accessors of properties it cannot bind as regular methods, the same pattern C# 14 made user-facing for extension-member disambiguation), and round-trips call sites to identical IL. Call sites already lower to direct accessor calls. The property-level attributes are kept on the first accessor under the 'property:' attribute target: it is not valid on methods, so csc emits nothing for it (CS0657 warning) and recompilation neither loses the attributes from the source nor misapplies them to the accessor. A comment on the first accessor documents the deliberate deviation. Visual Studio's metadata-as-source view drops such properties' attributes entirely. The assembly tree and tooltips are unaffected: they keep rendering the property node with its parameter list. Known limitation, inherent to any C# projection: recompiling the output produces plain methods, so VB.NET consumers of the recompiled assembly lose property syntax. Assisted-by: Claude:claude-fable-5:Claude Code	2 months ago
Siegfried Pammer	4783fe1d34	Add VBPretty spec for VB.NET parameterized properties C# has no syntax for named properties with parameters, so the expected output declares the accessors as ordinary methods, keeps the property-level attributes under the inert 'property:' attribute target (ignored by csc with CS0657), and consumes the properties through direct accessor calls, which Roslyn permits exactly for properties whose shape C# cannot bind. Red against the current decompiler, which emits a parameterless property whose body references the vanished parameters. Assisted-by: Claude:claude-fable-5:Claude Code	2 months ago

Author

SHA1

Message

Date

Siegfried Pammer

4c04e01882

Cover virtual, overloaded, and renamed-Implements parameterized properties

The renamed-Implements case exposed a gap: the accessor-method
declarations did not include the explicit-interface-implementation
forwarders generated from .override directives, so decompiled types did
not implement their interfaces and same-name implementations lost their
interface mapping. DecompileParameterizedProperty now emits the same
forwarder stubs as the ordinary method path.

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

2 months ago

Siegfried Pammer

832090c08d

Emit parameterized-property accessors as ordinary methods

C# cannot declare a named property with parameters: only the type's
default member gets indexer syntax, and reusing it via [IndexerName]
collapses for types with several differently-named indexed properties,
static properties, or explicit interface implementations. Emitting the
accessors as ordinary methods is the only fully general compilable
form, matches how C# consumes such properties (Roslyn exposes the
accessors of properties it cannot bind as regular methods, the same
pattern C# 14 made user-facing for extension-member disambiguation),
and round-trips call sites to identical IL. Call sites already lower
to direct accessor calls.

The property-level attributes are kept on the first accessor under the
'property:' attribute target: it is not valid on methods, so csc emits
nothing for it (CS0657 warning) and recompilation neither loses the
attributes from the source nor misapplies them to the accessor. A
comment on the first accessor documents the deliberate deviation.
Visual Studio's metadata-as-source view drops such properties'
attributes entirely.

The assembly tree and tooltips are unaffected: they keep rendering the
property node with its parameter list. Known limitation, inherent to
any C# projection: recompiling the output produces plain methods, so
VB.NET consumers of the recompiled assembly lose property syntax.

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

2 months ago

Siegfried Pammer

4783fe1d34

Add VBPretty spec for VB.NET parameterized properties

C# has no syntax for named properties with parameters, so the expected
output declares the accessors as ordinary methods, keeps the
property-level attributes under the inert 'property:' attribute target
(ignored by csc with CS0657), and consumes the properties through
direct accessor calls, which Roslyn permits exactly for properties
whose shape C# cannot bind. Red against the current decompiler, which
emits a parameterless property whose body references the vanished
parameters.

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

2 months ago

3 Commits (tests/829-lambda-param-modifiers)