Repository navigation
ref field support in .NET runtimes #63768
Description
There are several moving parts to support ref fields, this issue represents work in the actual runtime.
The high-level tasks for the runtime are below to address the ref fields work.
- CoreCLR support
- Port specific work from Hackathon project – https://github.com/dotnet/runtime/tree/feature/lowlevelhackathon
- Add runtime support for
reffields #63985 - Fix layout and GCInfo for ByRef fields. #64422
- Prevent placing ref fields on non-pointer boundaries #64520
- Validate
IntPtrand ByRef field overlap #65246
- Mono support
- API Proposal: Add
reffield feature support toRuntimeFeatureclass #64165 - Audit handling of null byrefs in runtime and libraries Box helpers do not handle null-valued managed pointers #70268
- Tooling support
- ECMA update – Proposed changes to ECMA 335 for ref field support #63659
- Delete the
ByReference<T>type and replace its use withreffields. - Diagnostics – Ensure SOS and VS can handle these new semantics.
- C# test cases – Comprehensive collection of testing for the runtime.
- Update CrossGen
- Update NativeAOT – CoreCLR and Mono.
- Language support - Merge features/ref-fields roslyn#62155
This contributes to enabling #45152.
Activity
AaronRobinsonMSFT commentedon Jan 13, 2022
/cc @mangod9 @jaredpar @davidwrighton @steveharter @lambdageek @dotnet/interop-contrib @fanyang-mono
jkotas commentedon Jan 14, 2022
I am not sure what this is about. The runtime does not have any special handling of these types. (Roslyn does - but you have it under separate check box.)
Also in the list should be: Delete the internal
ByReference<T>type and replace its use withreffields.jaredpar commentedon Jan 14, 2022
I believe @davidwrighton believes there is some spec work necessary before we can remove the notion of special types. Likely I think we will also need a feature flag in corelib to identify runtimes where Roslyn is safe to remove the notion of restricted types and depend solely on the type definition being correct. But agree bulk of the work here is in Roslyn.
AaronRobinsonMSFT commentedon Jan 14, 2022
/cc @tommcdon @noahfalk for Diagnostics impact.
vitek-karas commentedon Jan 18, 2022
We may possibly need dotnet/linker and mono/cecil work - it needs to be able to roundtrip assembly with ref fields correctly. I know it's not specifically about runtime - but it will be needed in order to use it in the runtime (since we run the code through linker during build).
AaronRobinsonMSFT commentedon Jan 18, 2022
This was brought up in the initial planning meeting. If I recall, @davidwrighton wasn't sure there should be any impact.
vitek-karas commentedon Jan 19, 2022
I created dotnet/linker#2519 to track the validation on the linker side - at the very least we should add some tests for this in the linker.
John0King commentedon Jul 1, 2022
How big is the size of a
ref? if it is fixed like 64bit , then a ref struct contains ref itself should also be legal likeclasssee
https://sharplab.io/#v2:EYLgZgpghgLgrgJwgZwLRLKsBLCAbAE2QBoCQBqAHwAEAmARgFgAoFl6gZgAIMvkYEcAMYwuAFSQQAcgHsCEFgG8WXVVwAOCbADdYEHhDDjJs+VwAyh0VwDcKtSwC+bVs05c6xiNLkQAwnhQyMhK9qruqhLepv6BwRZWigDmEDA2yKk2zsxqXGEe3JEmvgFByFwASthJABYwyZkZadnZLEA=
svick commentedon Jul 1, 2022
@John0King That is likely going to be fixed, see dotnet/roslyn#62098.
5 remaining items
AaronRobinsonMSFT commentedon Jul 19, 2022
Nope, this is done. Tests that can/should be in C# have been converted.
vitek-karas commentedon Jul 19, 2022
We haven't look at linker yet though... dotnet/linker#2519
@agocke
AaronRobinsonMSFT commentedon Jul 19, 2022
Shoot. That wasn't a checkbox :(
mangod9 commentedon Aug 8, 2022
is this expected to be complete this week?
vitek-karas commentedon Aug 8, 2022
Yes - @jtschuster is working on it in the linker repo right now.
John0King commentedon Aug 16, 2022
ref itself seem's being cut ? eg.
hamarb123 commentedon Aug 16, 2022
@John0King , ref fields should be in a ref struct, and is only .NET 7+, C# 11+
John0King commentedon Aug 16, 2022
@hamarb123 so there still no way to write a
BineryTreeor otherTreein struct ?hamarb123 commentedon Aug 16, 2022
(As far as I can tell) No, because a
reffield must be inref struct, but areffield cannot refer to arefstruct. If your value type is aunmanagedstruct, then you couldstackallocsome memory and manage everything manually (i.e. create a new allocator like malloc for that segment of memory, re-interpretation of memory for the value type, 'pointers' to other values which could just be an offset from the start etc.) then you could possibly create something of use, but it seems like a lot of effort to me and has the issue of the stackalloc'd memory running out, but thereffield wouldn't really help there and this could be done before already.John0King commentedon Aug 16, 2022
I think the
refof the field is not the same size of the struct, (I understand therefis likepointer, it should be 32/64 bit ) so a struct has arefor another struct of it's type ishamarb123 commentedon Aug 16, 2022
reffields are indeed implemented as managed pointers (which are just pointers that move with the GC). The reason that you can't stick them in any type (such as astructthat is not aref struct) is due to the span safety rules, if you want to read in-depth what they are and why they are what they are see here https://github.com/dotnet/csharplang/blob/main/proposals/low-level-struct-improvements.md.reffields toref structs are planned for C# 12 / .NET 8 currently.