References in C#'s default type system can be either an object or null, and if you try to use a null reference as if it was an object, a null reference exception is thrown, which can wreck things for end users. The only way to avoid this is to track in your brain whether every reference can be null, which generally requires checking for null frequently, which is tedious and easy to forget.
C# 8 added the ability to make references non-nullable by default. This means that a variable or function's type can indicate that parameters and return values can't be null, and the compiler can enforce it. References can be made nullable by appending ? to the type, just like for the already existing nullable types, and the compiler will check the code and emit warnings if such references are used in a way that could cause null reference exceptions.
This feature provides the tools to eliminate null reference exceptions via compile-time checks, which is a tremendous step forward.
Changes
All projects have had the following changes made:
C# language version is updated from 7.3 to 9 (which has some additional features that make nullable references more workable)
Nullable references are enabled and all code is updated to use them properly
Warnings are now treated as errors (except for a few specific ones that we want to be raised but don't want to fix)
The net7.0 target framework is replaced by net8.0 (which is as far as we can go unless and until we migrate away from Newtonsoft.Json)
The new indexes and ranges feature is used to replace substring operations
Additional fixes and small features
While working on the above, a few other problems and ideas came up.
@Linuxgurugamer recently replaced 9 mods twice in rapid sequence, and half of them didn't have their hashes update properly in the metadata (I made a spreadsheet to track the details). This was probably because of some combination of timezones being set wrong somewhere and SpaceDock's traffic server caching downloads. But later, when the 30-day cache purge job from the Infra ran, only the download_size property was updated, not the hashes! This is very strange and suggests the hashes are being cached when they shouldn't be.
Now when we detect that a ZIP file is deleted from the cache, we also purge its hashes from both the in-memory and on-disk caches. Hopefully this will make the hashes update properly after a cache purge.
The KSP2 mods have spurious missing-dependency inflation warnings currently because the SpaceWarpInfo validation check was embedded in the SpaceWarpInfo translator and I eliminated most of the duplicated metadata for multi-hosted KSP2 netkans in KSP-CKAN/KSP2-NetKAN#181.
Now this validator is separate and runs at the end after the multi-hosting merge step, so these warnings will go away.
The alert dot from #4133 only had two colors; now it blends from yellow to red gradually day by day
Motivation
References in C#'s default type system can be either an object or null, and if you try to use a null reference as if it was an object, a null reference exception is thrown, which can wreck things for end users. The only way to avoid this is to track in your brain whether every reference can be null, which generally requires checking for null frequently, which is tedious and easy to forget.
C# 8 added the ability to make references non-nullable by default. This means that a variable or function's type can indicate that parameters and return values can't be null, and the compiler can enforce it. References can be made nullable by appending
?to the type, just like for the already existing nullable types, and the compiler will check the code and emit warnings if such references are used in a way that could cause null reference exceptions.https://learn.microsoft.com/en-us/dotnet/csharp/nullable-references
This feature provides the tools to eliminate null reference exceptions via compile-time checks, which is a tremendous step forward.
Changes
Newtonsoft.Json)Additional fixes and small features
While working on the above, a few other problems and ideas came up.
download_sizeproperty was updated, not the hashes! This is very strange and suggests the hashes are being cached when they shouldn't be. Now when we detect that a ZIP file is deleted from the cache, we also purge its hashes from both the in-memory and on-disk caches. Hopefully this will make the hashes update properly after a cache purge.