Generics are not translated correctly

[mikes-gh]

It appear generics are not translated correctly in the coverage report. They contain the backtick which would be what it would be if you just did Type.Name

So for example Converter<T> will incorrectly translate to Converter`1 in the report.

See this for an explanation

https://stackoverflow.com/questions/17480990/get-name-of-generic-class-without-tilde

It would make reading the reports easier

[MarcoRossignoli]

Which report generator are you using?
Can you attach an image?

[mikes-gh]

coverage.cobertura.xml
Here the Generic is MudBaseInput<T> but it shows as MudBaseInput`1

 <class name="MudBlazor.MudBaseInput`1" filename="Base/MudBaseInput.cs" line-rate="0.9031999999999999" branch-rate="1" complexity="25">
          <methods>
            <method name="UpdateTextPropertyAsync" signature="(System.Boolean)" line-rate="1" branch-rate="1" complexity="1">
              <lines>

[MarcoRossignoli]

Usually the reports are not intended to be manually read, but as input for reports generator tool like https://danielpalme.github.io/ReportGenerator/
The name of object/members are simple standard ToString() that these tool convert accordingly.

Another sample, opencover report https://github.com/OpenCover/opencover/blob/master/samplexml/opencovertests.xml#L252

[mikes-gh]

@MarcoRossignol I use Report generator and the reports show it wrong as well because you have lost the original information.

Please see here how to correctly extract the type parameter names for generic types.
https://stackoverflow.com/questions/2448800/given-a-type-instance-how-to-get-generic-type-name-in-c

[mikes-gh]

This is the output from report generator you mentioned. You can see it is Hard to tell the generic types apart.

[mikes-gh]

Maybe you would accept a PR for this?

[MarcoRossignoli]

Oh I see what you mean, I apologize.

Need some help from my friend @danielpalme 😄 , Daniel do you have any concern about generics signature update in reports?
You've more experience than me on reports and maybe you can told us if makes sense update or if it's better keep generic name generation as-is.
Do you think it could break something on reporters side?

[mikes-gh]

@MarcoRossignoli @danielpalme you will need to encode the angle brackets so they don't break the xml.

< >

edit need to check the cobertura spec

[danielpalme]

Changing the XML should work. As @mikes-gh mentioned, brackets have to be encoded.

But I would suggest, that I change the behavior in ReportGenerator. That way it would work for all report types, not just for Coberatura files.

I could add a mapping that converts class names like this:

`1 -> <T> 
`2 -> <T1, T2> 
`3 -> <T1, T2, T3>

[mikes-gh]

@danielpalme That would be great thank you.
@MarcoRossignoli If we could also support the original signature with maybe a optin switch I will happily PR if you like.
It would be based around the function above.
So for example I could have

Converter<T, U>. as in my code. It just makes it easier to refer to the original method.

[danielpalme]

I just made the necessary code changes in ReportGenerator. Next release will contain the change.

[mikes-gh]

@danielpalme Thank you. 🙏 I presume if @MarcoRossignoli provides the original generic type names in the source with > < your report will be fine with that too?

[github-actions]

This issue is stale because it has been open for 3 months with no activity.

[github-actions]

This issue was closed because it has been inactive for 9 months since being marked as stale.