EnC: Runtime-specific Rude Edits

[tmat]

.NET Core, .NET Framework and Mono have (or will have) different limitations. We need a debugger interface that we can query for the runtime capabilities and report Rude Edits accordingly.

Debugger work item: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1295107

Runtime work item: dotnet/runtime#50111

[lambdageek]

I think roslyn should expose an API to specify the runtime type. (So the debugger, or dotnet watch can call it to initialize roslyn).

I don't think it makes sense to make the capabilities too fine-grained just specify the runtime

[lambdageek]

/cc @tommcdon @mikem8361

[mikem8361]

I hope just specifying the runtime (coreclr or mono) and the runtime version will be sufficient for Roslyn to switch on for the capabilities. Roslyn already knows/assumes what are Rude Edits for coreclr. Does it make sense to also have Roslyn built-in assumptions about Mono? I would like to keep this simple. Is the runtime version (of either runtime) sufficient to future proof when more edit capabilities are added?

[tmat]

I'd start to with a document that lists all the edits that are supported on .NET and not supported on Mono today. Then we can see how many of these edits are there.
If not many then I'd prefer if we defined enum listing each of these and the runtime would send a list to Roslyn. In future, when Core CLR or Mono adds support for a new edit, it would define an enum value for the edit and include it in the list - the first set of values in the enum would be "negative" the new features would be "positive" (additions) wrt .NET Framework baseline. For .NET 5/.NET Framework the list would be empty.

Using capabilities is preferable since it doesn't tie Roslyn to specific versions of the CLR/Mono.

[mikem8361]

Can you make that list for .NET Core/Framework? What granularity do we define one of the enums for a supported edit? I'm trying to get my mind around how to define an concrete enum for each entry in supported ENC edits when there are usually 2 or exceptions.

[tmat]

We don't need the list for .NET 5/Framework. We only need to find out how Mono is different from .NET 5/Framework. The supported edits listed in https://github.com/dotnet/roslyn/blob/main/docs/wiki/EnC-Supported-Edits.md are not what we should be concerned with on the runtime level. They are end-to-end limitations. Some of them are compiler imposed some of them debugger imposed and some runtime imposed. We are only interested in what metadata and IL edits can or can't be done when compared to .NET 5/Framework. E.g. let's say Mono can't currently add a field into a class (I'm not sure if it actually can). Then we'd add enum value AddFieldDefinitionNotSupported ("negative" capability).

An example of a potential member of this enum in future versions of .NET Core would be e.g. UpdateInGenericContextSupported if the runtime supported editing method bodies of generic methods and of methods in generic types. This is not currently allowed in .NET 5/Framework and thus would be a "positive" capability.

[tmat]

@tommcdon @mikem8361 FYI: filed https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1295107 on the debugger, but we'll also need some runtime API the debugger can call. For both .NET 6 and Mono.

/cc @isadorasophia

[lambdageek]

but we'll also need some runtime API the debugger can call. For both .NET 6 and Mono.

@tmat The runtime API would also be needed for the non-debugger CLI, right? Would a single managed API (to be called by the debugger using func eval) be sufficient?

We are only interested in what metadata and IL edits can or can't be done when compared to .NET 5/Framework. E.g. let's say Mono can't currently add a field into a class (I'm not sure if it actually can). Then we'd add enum value AddFieldDefinitionNotSupported ("negative" capability).

The current supported edits list (at the IL level) is:

• modify MethodDef row RVA column to point to new IL
• add new rows to these tables: AssemblyRef, TypeRef, TypeSpec, MemberRef, StandAloneSig, MethodSpec
• extend Guid, US, Strings and Blob heaps

That's it. There will be a few more things supported by the time .NET 6 is RTM, but today this is the list. I'm not sure how to translate that into a collection of negative enum values -- let me know.

[tmat]

Can you add a MethodDef or TypeDef?

[lambdageek]

Can you add a MethodDef or TypeDef?

I don't think we will be able to add a MethodDef to an existing class in net6. (Possibly adding non-virtual instance or static methods might be possible - I need to check how much stuff will break)

The highest priority things that I'd like to get into .net 6 are:

1. modify existing property bodies (just need to allow a few modifications to Property, PropertyMap, MethodSemantics as long as they're not actually changing anything)
2. allow adding TypeDef. allow adding a NestedClass where the enclosing class already exists. Allow adding rows to MethodDef, Field, Param, Event, Interface, etc etc... as long as they belong to a newly-added TypeDef (ie you can define new classes. Either toplevel, or nested in an existing class).

[tmat]

I don't think we will be able to add a MethodDef to an existing class in net6. (Possibly adding non-virtual instance or static methods might be possible - I need to check how much stuff will break)

.NET Core does not allow adding virtual/abstract members either, but non-virtual and static are important for method body edits as well. Otherwise we won't be able to add a new local function or lambda within an existing method body.