The Member field of CallsAttribute and CalledByAttribute currently just contains the member's name. Specifying the full signature would be better for removing ambiguity.
For example, instead of:
[Calls(Type = typeof(Path), Member = "Combine")]
It could be:
[Calls(Type = typeof(Path), Member = "Combine(System.String, System.String)")]
The Type?[] MemberTypes proposal has the advantage of succinctness and clicking in decompilers. It should be enough for most cases. However, it cannot cover all scenarios. For example, the following code is legal:
public unsafe static class Test
{
public static void Stuff(out int value) => value = default;
public static void Stuff(int value) { }
public static void Stuff(int* value) { }
public static void Stuff(delegate* unmanaged[Cdecl]<void> value) { }
}
in, out, and ref can't be used so using Type? parameters inevitably creates an ambiguity. To iterate over the possibilities:
If the out is discarded, it conflicts with Stuff(int).
If it's converted to a pointer, it conflicts with Stuff(int*)
If it's treated as null, it conflicts with the function pointer overload.
A string encoding is the only way to remove all ambiguity. However, that is overly verbose and less useful. For the vast majority of cases, using an array of typeof will suffice.
A specified return type is not necessary for removing ambiguity.
Due to the complexity and questionable usefulness of string method signatures, I consider the Type?[] MemberTypes proposal to be the superior design.
Alternative names might be MemberParameters, MemberParameterTypes, or ParameterTypes.
The
Member
field ofCallsAttribute
andCalledByAttribute
currently just contains the member's name. Specifying the full signature would be better for removing ambiguity.For example, instead of:
It could be:
Or:
The
Type?[] MemberTypes
proposal has the advantage of succinctness and clicking in decompilers. It should be enough for most cases. However, it cannot cover all scenarios. For example, the following code is legal:in
,out
, andref
can't be used so usingType?
parameters inevitably creates an ambiguity. To iterate over the possibilities:out
is discarded, it conflicts withStuff(int)
.Stuff(int*)
A string encoding is the only way to remove all ambiguity. However, that is overly verbose and less useful. For the vast majority of cases, using an array of
typeof
will suffice.A specified return type is not necessary for removing ambiguity.
Due to the complexity and questionable usefulness of string method signatures, I consider the
Type?[] MemberTypes
proposal to be the superior design.Alternative names might be
MemberParameters
,MemberParameterTypes
, orParameterTypes
.