[Mono-dev] Porting mcs to IKVM.Reflection

[Kornél Pál]

Hi,

mcs creates an assembly, then creates types, and only after that is 
processing the custom attributes. This is how attributes and even 
assembly name (not the name part) can change after definition. Although 
there are some other self referencing cases, this order of 
creation/definition is required especially when building mscorlib.dll. 
At least some cases of these requirements could be eliminated by doing 
dependency analysis but there is no use to introduce extra complexity 
when the solution is very simple.

All of these functions are implemented as hacks in Mono's 
System.Reflection.Emit.

Blob encoded pseudo custom attributes are supported by Mono. I've added 
decoding because they weren't ignored, exceptions were thrown instead.

I think that the only problem is that I've removed the exception when 
emitting backward jumps but since things were working so far, I haven't 
tried to resove that issue yet. (This is a work-in-progress state.) 
Unlike Java, C# has support for backward jumps, so does 
System.Reflection.Emit so support for that will have to be implemented.

Some notes on IKVM.Reflection:

First of all, thank you very much for creating it, since it's very unique.

Based on your questions I belive that you are trying to remain 
compatible with MS.NET. This good, because both IKVM and mcs has a 
dynamic mode that is generating code for direct execution that requires 
System.Reflection.Emit. And to some extent enables IKVM.Reflection to be 
a drop-in replacement for System.Reflection.Emit on runtimes that have 
no built-in support.

I on the other hand belive that removing arbitrary limitations of 
System.Reflection.Emit (like preventing access to TypeBuilder's 
member-builders), and adding missing functionality would make sense.

Mono.Cecil is a great tool but it targets tools operating on metadata 
rather and is too abstract and complex for compilers. It also has a 
larger memory footprint. So I belive that there is a need for 
IKVM.Reflection as a replacement for MS.NET's System.Reflection.Emit as 
well.

I also like the concept of having a Universe since that makes possible 
to have multiple compiler instances in the same AppDomain.

I belive that pseudo custom attributes and unmanaged resource generation 
does not fit well to the concept of System.Reflection.Emit. I would 
rather remove support for both of these and introduce __methods for 
setting metadata that currently is built from pseudo custom attributes. 
Unmanaged resource generation could be automated (and customized) by 
using a dedicated class. This would be much faster than encoding (either 
binary or just the constructor arguments) and then decoding pseudo 
custom attributes.

I also belive that CustomAttributeData should not be used as a provider, 
__GetCustomAttributes (non-standard since is returning constructor 
arguments rather than class instance) methods should be added to 
reflection classes. An ICustomAttributeProvider interface (with 
IsDefined and __GetCustomAttributes methods) would be very useful as well.

As a conclusion I would be happy to see features (that make sense) in 
IKVM.Reflection.Emit that are not present in System.Reflection.Emit.

Kornél

Jeroen Frijters wrote:
> Hi,
> 
> Thanks for the IKVM.Reflection patches. I have a few questions about some of the changes.
> 
> - Why are the various _SetAttributes methods and the AssemblyBuilder.__SetName() methods necessary?
> - Do you really need blob encoded pseudo custom attributes in the version info? I intentionally don't suppor that (and also include the attributes as regular attributes) to be compatible with .NET
> - Why are all the stack height asserts commented out in ILGenerator, do you think they are wrong?
> 
> Thanks,
> Jeroen
> 
>> -----Original Message-----
>> From: Kornél Pál [mailto:kornelpal at gmail.com]
>> Sent: Tuesday, May 04, 2010 2:03 PM
>> To: mono-devel
>> Cc: Miguel de Icaza; Marek Safar; Jeroen Frijters
>> Subject: Porting mcs to IKVM.Reflection
>>
>> Hi,
>>
>> Inspired by http://tirania.org/blog/archive/2010/Apr-27.html I gave a
>> try to port mcs to IKVM.Reflection.
>>
>> I addition to being able to have a single binary, mcs could run on
>> MS.NET and we would not have to break MS.NET compatibility in
>> System.Reflection.
>>
>> I've attached some work in progress patches both for mcs and
>> IKVM.Reflection.
>>
>> I was impressed by the result that mcs is able to bootstrap itself,
>> compile mscorlib.dll and its other requirements, and the resulting mcs
>> is able to compile a bunch of Mono assemblies.
>>
>> Missing features:
>> - security attributes
>> - embedded resources
>> - .netmodule support
>> - debug info
>>
>> Also note that I was unable to figure out what MakeExpression methods
>> are supposed to do but I had to disable them because they need
>> System.Reflection types.
>>
>> mcs pathes are licensed under the MIT/X11 license.
>> IKVM.Reflection patches are licensed under the zlib license.
>>
>> Kornél