#12 sig attributes lose information for generics

[Anonymous]

Examples:
Method returning System.Collections.Generic.Dictionary<System.UInt32, My.Record> has sig attribute beginning "unsigned intMy.Record "
-- indeed any generic containers with concrete types applied are lost in reports be they argument types or return types

Method with form T1 Method<T1,T2,T3,T4>(T2 a, T2 b, T3 c) has sig="&lt;4&gt; (, , )"
-- open type parameters are not marked with any token

These make formatting results for reports or reconciling with other introspective or reflective analyses of the same code a more difficult job of parsing.
Possibly related to the nested class name formatting issue http://sourceforge.net/tracker/?func=detail&aid=3018557&group_id=175733&atid=874418

[Shaun Wilde]

Not sure what token we would use since there is no actual concrete type for that method - we cover usage of the method regardless of type - we don't have different coverage per typed method i.e.

void Method<T>(T value){}

Method<int>(1);
Method<string>("string");

would show 2 visits to that method.

If I have misunderstood the issue, please expand.

[Mr. Tines]

Given a method in class Program with signature

T2 Stub<T1, T2, T3>(T1 _arg7, T2 _arg6, T3 _arg5)

Mono.Cecil 0.92 reports its full name as

T2 reflect.Program::Stub(T1,T2,T3)

FxCop 1.36 is a little more verbose, giving (return type full name + method full name)

type parameter.T2 reflect.Program.Stub(type parameter.T1,type parameter.T2,type parameter.T3)

So, for the latter, something in this sort of style.

[Shaun Wilde]

Okay, changed this to a feature request as the current behaviour (as far as I can tell) has been like this since 09/2008. I think a possible fix would be to add a new attribute with a more verbose output - rather than change the current output which may a negative impact on existing users.

[Steven Gilham]

The composition for classes, signatures and other type-related names seems all to be hand-rolled in the native code rather than being dispatched to one or other of the pre-existing mechanisms in native code (hence issue 3018557 about the lack of punctuation in nested class names, and this issue).

While the existing name formats are probably something we're stuck with for backwards compatibility, providing a more robust mechanism for matching the method mentioned in the XML output and its reflective or introspective representations (one that doesn't require parsing of the existing lossy output to resolve overloads) would be a useful enhancement.

The method metadata token provides a module-unique numeric label for each method, and can be matched by reverse look-up to reflection or Mono.Cecil introspection method representations, and by use on internal methods in FxCop introspection. Allowing the option of including this value in the output would then give downstream consumers the scope to format the names according to the managed representation of their choice.