Skip to content

migrate core library to use nullable reference types - #157

Draft
hahn-kev wants to merge 6 commits into
masterfrom
enable-nrt-core
Draft

migrate core library to use nullable reference types#157
hahn-kev wants to merge 6 commits into
masterfrom
enable-nrt-core

Conversation

@hahn-kev

@hahn-kev hahn-kev commented Jul 9, 2026

Copy link
Copy Markdown

After seeing some fixes from @imnasnainaec, I figured I'd try my hand at enabling NRT and fixing some issues that came up.

There's currently 4 warnings still in place, I wasn't sure what the right call would be, so we can leave them in or come up with a fix together. They are:

    src\L10NSharp\XLiffUtils\XLiffBody.cs(173,22): warning CS8604: Possible null reference argument for parameter 'key' in 'string ConcurrentDictionary<string, string>.this[string key]'.
    src\L10NSharp\XLiffUtils\XLiffBody.cs(175,22): warning CS8604: Possible null reference argument for parameter 'key' in 'string ConcurrentDictionary<string, string>.this[string key]'.
    src\L10NSharp\XLiffUtils\XLiffBody.cs(201,21): warning CS8604: Possible null reference argument for parameter 'key' in 'string ConcurrentDictionary<string, string>.this[string key]'.
    src\L10NSharp\XLiffUtils\XliffLocalizationManager.cs(126,12): warning CS8618: Non-nullable property 'DefaultStringFilePath' must contain a non-null value when exiting constructor. Consider adding the 'required' modifier or declaring the property as nullable.

There's a lot of code that used XLiffTransUnit.Id with the assumption that it's not null, however it can be, I've fixed many of those.

Some places I've added checks like if x is null throw new exception this is only in cases where we would have thrown anyway when accessing a property on x later down, so while this may not fix a bug, it does give much better feedback as to what was null.

There's a few places where code may have been returning null, which are now returning an empty string, these were changed due to the method already returning an empty string elsewhere, with the assumption that the method was written to never return null, and these cases were missed.

One change I did make is to constrain ILocalizationManagerInternal<T> T to only be a class, this may effect consumers, but I don't think that's possible as the only implementation of this internal interface is a T of XLiffDocument, and I think if anything else were to be used there would be a crash at runtime, so I don't think it's a problem.


This change is Reviewable

@hahn-kev
hahn-kev requested a review from imnasnainaec July 9, 2026 06:42
@github-actions

github-actions Bot commented Jul 9, 2026

Copy link
Copy Markdown

Test Results

    7 files  ±0  124 suites  ±0   31s ⏱️ +4s
187 tests ±0  182 ✔️ ±0    5 💤 ±0  0 ±0 
714 runs  ±0  699 ✔️ ±0  15 💤 ±0  0 ±0 

Results for commit f14ab15. ± Comparison against base commit ae81ffb.

♻️ This comment has been updated with latest results.

imnasnainaec

This comment was marked as outdated.

@imnasnainaec

This comment was marked as outdated.

* Address NRT review feedback and clear remaining warnings

- MapToExistingLanguageIfPossible now returns the empty string (not null)
  for empty input, honoring its [return: NotNullIfNotNull] contract.
- Removed the incorrect [MemberNotNullWhen(false, Id, Source, Target)] from
  XLiffTransUnit.IsEmpty: IsEmpty is a conjunction, so !IsEmpty does not
  imply all three members are non-null. Adjusted ToString and
  XLiffBody.AddTransUnitRaw, which relied on that bogus guarantee.
- DefaultInstalledStringFilePath now throws a clear InvalidOperationException
  instead of passing a possibly-null folder to Path.Combine.
- StringCache is backed by a nullable field and throws a clear
  InvalidOperationException instead of being `null!` and NREing when the
  minimal constructor was used.
- MergeXliffDocuments hoists the trans-unit id once per iteration and skips
  units without one, replacing ten null-forgiving `tu.Id!` uses.
- Fixed the four remaining warnings: CS8604 in XLiffBody (hoisted documented
  locals) and CS8618 for DefaultStringFilePath (defaults to string.Empty).

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants