Change EF Core codebase to use C# nullable references

[roji]

In addition to #10347, which is about user-facing changes related to the new C# 8 nullable reference feature, we can consider changing parts or all of the EF Core codebase to use nullable references internally. This would improve general code quality, test the new C# feature, etc. As the codebase already uses JetBrains annotations ([NotNull], [CanBeNull]), we wouldn't be starting from scratch.

[ajcvickers]

Agreed, but let's make sure we understand how this will work when targeting netstandard2.0 (i.e. .NET Framework) which will not have C#8 support.

[pmiddleton]

From what I have read from the C# and framework teams async streams, indexers and ranges will require netstandard 2.1 which .NET Framework will not support.

The default interface member feature requires a runtime change which will not be put into .NET Framework.

See Platform Dependencies here https://blogs.msdn.microsoft.com/dotnet/2018/11/12/building-c-8-0/

It appears nullable references will be supported. I'm putting the over/under at 5000 warnings being emitted from the current code base :)

[ajcvickers]

@pmiddleton We may need to cross-compile for multiple TFMs, but also we may not to, since often the compiler using things like pattern matching. @divega has been thinking through some of this stuff.

[roji]

Specifically for nullable references, if I understood things correctly there doesn't seem to be any issue with using them in codebases which target netstandard2.0 (or even older) - the compiler simply generates attributes at various levels which inform consuming code as to the nullability status of parameters, properties etc. Even the nullability attributes themselves are generates into the assembly, to prevent any sort of dependency on newer platforms etc.

The situation seems to be indeed different with async streams and indexers/ranges - but we may want to discuss these separately and leave this issue only for nullability.

The big question, as @pmiddleton hinted, is how to tackle the conversion with such a big codebase... It could be a single concentrated effort by a single person, or it could be a gradual process whereby each "owner" converts their own part of the codebase.

In any case, it may be a bit early to attempt this - it's probably a good idea to check with the C#/Roslyn team whether this is a good time or not.

[roji]

Note: this issue covers null-annotating two different things in the EF Core codebase:

1. User-facing APIs. I think this should be high priority: if I understand correctly, EF Core 3.0 will ship at the same time as C# 8, and there will be a very clear user expectation for newly-released APIs to have this.
2. Provider-facing, internal and private code. This is probably lower-priority - it hardens the codebase against null-related errors, but does not otherwise affect users directly.

Apart from this we also have #10347, which is about having the new nullability affect model-building.