Dataflow support for ref fields #2947
Conversation
|
This looks promising, but I think we should tackle some other stuff first:
And only once we have these and fixed any round-trip or crashing issues, we may start looking into improving data over ref fields. Honestly ref fields of System.Type type are probably going to be very rare... and even rarer to have annotations, it would be perfectly OK if in .NET 7 we shipped without proper data flow around them. |
…into refFieldTests
PR: #2960 -- Add ILVerification
PR: #2952
PR: #2952 -- All fields of structs should be kept
PR: #2952
This PR |
| case ReferenceValue referenceValue: | ||
| throw new NotImplementedException ($"Unhandled dereference of ReferenceValue of type {referenceValue.GetType ().FullName}"); | ||
| // Incomplete handling for ref values | ||
| case FieldValue fieldValue: |
There was a problem hiding this comment.
Do we need this case? I think it's the same as the default.
There was a problem hiding this comment.
Yeah, it's probably not necessary, but I thought it might be nice to have the case just to point out that it's not fully / correctly implemented. I can remove it if you feel like it's just noise.
src/linker/Linker.Steps/MarkStep.cs
Outdated
| Code.Ldsflda | ||
| => ReflectionMethodBodyScanner.RequiresReflectionMethodBodyScannerForAccess (Context, (FieldReference) instruction.Operand), | ||
| // For ref fields, ldfld loads an address which can be used to store values to annotated fields | ||
| Code.Ldfld when ((FieldReference) instruction.Operand).FieldType.IsByRefOrPointer () |
There was a problem hiding this comment.
I wonder if it would be better to look for indirect stores - the other cases above check for writes that could impose requirements, and an indirect store would be the way to get there with a ldfld of a ref field. I expect it's also less common than ldfld.
There was a problem hiding this comment.
I don't think there's an easy way to tell where the value is being stored or what value we're storing to it since stind operates on addresses on the stack. And this will filter to only be ref fields or pointers that also have annotations, so it shouldn't cause too many more method bodies to be analyzed for dataflow. I think that's why the previous cases also look for ldflda.
Adds support and basic tests for ref fields. The tests ensure that a value written to an ref field is properly annotated, or an address written to a ref field has a properly annotated value, but there are some holes that can be created by assigning the address of a local or over-annotated value to an annotated ref field. Commit migrated from dotnet/linker@1ef0acf
Adds support and basic tests for ref fields. The tests ensure that a value written to an ref field is properly annotated, or an address written to a ref field has a properly annotated value, but there are some holes that can be created by assigning the address of a local or over-annotated value to an annotated ref field. Tracking issue: #2946
For example:
The linker also doesn't recognize ldind.ref, so when a ref variable is assigned by value to a ref field, the linker will warn for a unknown value. Tracking issue: dotnet/runtime#85465
For example: