Ref safety: replace uint scope with struct SafeContext #75647
Conversation
dotnet-issue-labeler
bot
added
Area-Compilers
untriaged
Co-authored-by: Jan Jones <jan.jones.cz@gmail.com>
|
Based on offline discussion and investigation, I am thinking this is not the right time or order to introduce a new term. Terms which we want to match specification, should be introduced first in specification. ECMA has written quite a bit already about these features in terms of safe-context, so, backing that train up also requires a proportional level of justification and work. The goal of this PR is to simply improve understandability of this area. So let's do that on a standalone basis for now. Will update PR title prior to merging. |
Semes like the safe choice in this context |
| /// </summary> | ||
| public SafeContext Wider() | ||
| { | ||
| Debug.Assert(_value >= CurrentMethodRaw); |
There was a problem hiding this comment.
Why CurrentMethodRaw vs. ReturnOnly? It should be valid to get a wider scope from a ReturnOnly context.
There was a problem hiding this comment.
The purpose of the method is to "exit" a local scope, alongside Narrower() to "enter" a local scope. It's not intended to, for example, transition between the well-known "returnable" scopes. (We do allow this method to return ReturnOnly, though, to allow for uniformity when exiting the "top-level" block of a method in the visitor.)
Co-authored-by: Jared Parsons <jared@paranoidcoding.org>
|
It looks like following tests are failing in Release_32, which appear unrelated to my changes:
|
RikkiGibson
changed the title
Update: renamed the new type to SafeContext to match the language standard. #75647 (comment)
The 'struct Lifetime' represents a shift in philosophy toward a type-like solution for ref safety. Rather than directly using uints, equality/relational operators, Math.Min/Max, etc. we express things in terms of "convertibility" of these semi-opaque Lifetime values as well as 'Intersect' and 'Union' operators. Hopefully you will find that this improves the clarity of the code quite a bit.
I am adopting the term "lifetime" rather than "escape scope", "safe to escape", "ref-safe-scope", etc. very deliberately here. I am coming around to the opinion that using the term "lifetime" is much clearer than any of the above.
Separately, I am hoping to publish a spec for this area which will hopefully demonstrate that improvement in clarity. That spec will probably be an expansion upon low-level-struct-improvements.md#annotations, but as a standalone document. The goal of that document would be to succinctly and fully define all the ref safety rules in the language, and provide a basis for deciding if any given program is "ref-safe".
Because the dynamics of how ref lifetimes can be nested and related is much, much simpler than for types in C#, you can think of this as more of a metaphor for how things work than anything else. We are not "reifying" the concept of a lifetime as a type, we are not appending this concept to the symbol model in any way, etc. In the compiler it's just a "temporary" concept which is introduced for the purpose of these safety checks and diagnostics and then dropped.