Ensure ClrInstrumentationEngine handles ref fields
wiktork opened this issue · 7 comments
May be particularly impactful with regards to signature parsing.
See the additional ECMA-335 changes too - dotnet/runtime#63659
@wiktork Any updates on this investigation?
@wiktork Any updates on this investigation?
We haven' started it yet. We have talked about this a bit since there is a risk that our IL decoding logic might just crash if it comes across something like this. Hopefully it won't be impactful in the short term because ref fields will be rare in production code for the time being.
We have talked about this a bit since there is a risk that our IL decoding logic might just crash if it comes across something like this. Hopefully it won't be impactful in the short term because ref fields will be rare in production code for the time being.
Thanks @delmyers. I agree this is a potential concern. Something to note is that Span<T> and a few other types will be updated to have ref fields so it might show up in production code as people move onto .NET 7.
@AaronRobinsonMSFT I hope we will still have a bit of time before this becomes a big issue, since someone would have to decode a method that references the type first. There are some scenarios where that is more likely.
@AaronRobinsonMSFT Is there an easy way for our partners to install and test these new features? I think that the easiest way for us to find issues is to get partners to write tests that use them, so we can work together to fix issues. We, of course, should be adding tests to this codebase, too.
@delmyers The C# language support doesn't presently exist. I wrote a library in IL that could be used to try out things and sent that to @wiktork. I can share with you as well. The support for ref fields is in the nightly .NET 7 builds and should also be in preview 3+.