[RFC FS-1060] Nullness checking

[dsyme]

This is a prototype implementation of RFC FS-1060 nullable reference types

See tests\fsharp\core\nullness\test.fsx for testing and samples.

TODO:

• implement import of .NET metadata
• implement emit of .NET metadata
• resolve all unresolved issues in RFC
• implement match x with null -> ... | x -> ... implied use of NonNull pattern
• make null and NonNull be considered disjunctive discriminators in pattern matching
• resolve all // TODO NULLNESS
• ambivalent/oblivious annotations are not being shown at all in visual output. Consider what to do about these. They should likely be dropped but give a supplementary sentence "Some types shown are ambivalent to null checking for compatibility reasons".
• add testing
• get it green
• performance testing
• should nullness be supported on ref tuples and anon tuples
• check signature compatibility

DONE:

• allow Foo<string?>, currently Foo< string? > with a space between ? and > is needed, need to token smash ?> token in tyargs

[cartermp]

RFC link for folks interested: fsharp/fslang-design#317

[dsyme]

@cartermp @TIHan I done a couple of major things on this

• The F# metadata blob is now binary compatible. The nullness information is stored in a secondary resource blob and integrated into the TAST during unpickle. THis means the FSHarp.Core produced with nullness information can be consumed by older compilers.

• Added hacky /langversion and /checknulls and /test:AssumeNullOnImport flags

  • /langversion:4.5 feature is totally off.
  • /langversion:5.0 (the default) nullness inference happens just no warnings are emitted. If you use string? syntax you get a warning
  • /langversion:5.0 /checknulls nullness inference happens and warnings are emitted.
  • /langversion:5.0 /checknulls /test:AssumeNullOnImport nullness inference happens, warnings are emitted and we interpret all reference types in .NET assemblies as nullable (rather than oblivious)

The compiler changes are now architected to be "neutral" , i.e. all nullness information is set to Oblvious everywhere for /langversion < 5.0. This makes me much more confident that we aren't messing with the existing behaviour and performance of the compiler. Also we can assess the impact of the language feature independently of other issues, and before even turning it on (there are memory and performance costs associated with the language feature even when it is not on)

[cartermp]

@dsyme How difficult would it be to split that out into a separate PR? Or is it more practical to just merge this into master?

[dsyme]

I have also added

• implementation of 'T when 'T : not null constraint. Needs to be correlated with .NET metadata

[dsyme]

@dsyme How difficult would it be to split that out into a separate PR? Or is it more practical to just merge this into master?

Those things are integral to this PR, though the "langversion" switch could be carved out.

We should merge this into master soon after confirming the overall performance degradation for the feature, to avoid massive conflicts (I'm working through the conflicts above now)

[cartermp]

Okay. We don't have a date for this, but once we lock down on compiler/core library changes for VS 16.0, we can "lock" and merge this into master.

[dsyme]

OK, good news!

• I have successfully enabled nullness checking on FSharp.Compiler.Private.dll using the prototype

This is a very large codebase so it's good to see it checks

Some notes about this work so far and its limitations are in fsharp/fslang-design#339

[brettfo]

Closing due to branch rename nullness -> feature/nullness.