Fix nullness flow for type aliases after null pattern

[Copilot]

Problem

When nullness checking is enabled, variables in non-null branches of match expressions should be refined to non-null types, but type aliases were not being preserved during this refinement process.

Consider this example:

type objnull = obj | null

let getEnvAliasObj (_: string) : objnull = failwith "stub"

let valueAliasObj =
    match getEnvAliasObj "ENVVAR" with
    | null -> "missing"
    | x -> x.ToString() // x should be refined to obj (non-null), preserving the alias

Previously, the type alias objnull would be stripped during nullness refinement, and the variable x would lose its connection to the original type alias.

Root Cause

The issue was in the removeNull function within TcMatchClause in CheckExpressions.fs. The original implementation used:

let removeNull t =
    let stripped = stripTyEqns cenv.g t
    replaceNullnessOfTy KnownWithoutNull stripped

This approach stripped type abbreviations using stripTyEqns and then applied the nullness refinement to the stripped type, losing the original type alias information.

Solution

Modified the nullness refinement logic with a targeted approach that only affects type abbreviations:

let removeNull t =
    // Check if this is a type abbreviation that we should preserve
    match t with
    | TType_app (tcref, tinst, _) when tcref.Deref.IsTypeAbbrev ->
        // Preserve the type abbreviation structure while refining nullness
        TType_app (tcref, tinst, KnownWithoutNull)
    | _ ->
        // Use existing logic for non-abbreviation types
        let stripped = stripTyEqns cenv.g t
        replaceNullnessOfTy KnownWithoutNull stripped

This surgical approach:

1. Detects actual F# type abbreviations using tcref.Deref.IsTypeAbbrev
2. For type abbreviations: preserves the original type structure while setting nullness to KnownWithoutNull
3. For all other types: uses the existing logic unchanged to avoid any regressions

Impact

• ✅ Type aliases like objnull = obj | null are now preserved in non-null branches
• ✅ Variables in non-null match branches are correctly refined to non-null types
• ✅ Maintains full compatibility with existing nullness checking functionality
• ✅ No impact on non-abbreviation types (preserves all existing behavior)

Fixes #18488

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[github-actions]

❗ Release notes required

@copilot,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/10.0.100.md	No release notes found or release notes format is not correct

[T-Gro]

@copilot : You broke the compiler, this change only makes null elimination worse:

e.g .this now fails:

    let map f (arr:_ ProvidedArray) : _ ProvidedArray = 
        match arr with
        | null -> null
        | notNull -> notNull |> Array.map f

src/Compiler/TypedTree/TypeProviders.fs(30,33): error FS3261: (NETCORE_ENGINEERING_TELEMETRY=Build) Nullness warning: A non-nullable ''a array' was expected but this expression is nullable. Consider either changing the target to also be nullable, or use pattern matching to safely handle the null case of this expression.

You also created this massive tryRefineToNonNullPreservingAbbrev but did not use it.
and your changes in CheckExpressions.fs on line 10740 are not doing the real thing, are not even abbreviation related, and just breaking what worked.

Start from scratch and try a different approach which will only fix the bug in case of a type abbreviation, not break what already used to work.

[T-Gro]

@copilot : See the comment above.

[Copilot]

@copilot : You broke the compiler, this change only makes null elimination worse:

e.g .this now fails:
...

I've reverted all previous changes and implemented a targeted fix (commit 6ebd419). The new approach only affects actual type abbreviations detected via tcref.Deref.IsTypeAbbrev, leaving all other types unchanged. This preserves the existing behavior for cases like the TypeProviders.fs example while only fixing the specific issue with type aliases like objnull = obj | null.

[Copilot]

@copilot : See the comment above.

Addressed with targeted fix in commit 6ebd419. The solution now specifically detects type abbreviations and preserves their structure during nullness refinement, without affecting the existing logic for other types.