Nullness FS3261: pinpoint receiver range, name the member & binding in dot-access warnings

[T-Gro]

Fixes #19658, Fixes #17409

Architecture

New ContextInfo.MemberAccessOnNullable threads receiver range + member name + optional binding name through constraint solving. When FS3261 fires during dot-access, a dedicated ConstraintSolverNullnessWarningOnDotAccess emits a targeted diagnostic instead of the generic "types do not have compatible nullability".

Before → After

1. Simple method call on nullable receiver

let pad (x: string | null) = x.PadLeft(10)

• Before: FS3261 on x.PadLeft(10) — Nullness warning: The types 'string' and 'string | null' do not have compatible nullability.
• After: FS3261 on x — Nullness warning: Possible dereference of a null value when accessing member 'PadLeft' on the nullable value 'x' of type 'string | null'.

2. Chained call — warning targets the actual nullable hop

let f (x: string | null) = x.Trim().Length

• Before: Two FS3261 on x.Trim().Length and x.Trim() — Nullness warning: The types 'string' and 'string | null' do not have compatible nullability.
• After: Single FS3261 on x — Nullness warning: Possible dereference of a null value when accessing member 'Trim' on the nullable value 'x' of type 'string | null'.

3. Multi-line receiver gets "See also" pointing at call site

let process (data: string | null) =
    data
     .ToUpper()

• Before: FS3261 on .ToUpper() — Nullness warning: The types 'string' and 'string | null' do not have compatible nullability.
• After: FS3261 on data — Nullness warning: Possible dereference of a null value when accessing member 'ToUpper' on the nullable value 'data' of type 'string | null'. See also <line with .ToUpper()>

4. Property chain — warning pinpoints where nullability starts

// Given: type Foo with member Prop : Bar | null
let g (foo: Foo) = foo.Prop.ToString()

• Before: FS3261 on foo.Prop.ToString() — Nullness warning: The types 'Bar' and 'Bar | null' do not have compatible nullability.
• After: FS3261 on foo.Prop — Nullness warning: Possible dereference of a null value when accessing member 'ToString' on a nullable expression of type 'Bar | null'.

---

Entity.Typars cleanup (included because it fixes a parallel test race exposed by the new tests)

Entity.Typars changed from method Typars(m: range) to property. The range parameter was unused for F# types (always NotLazy — typars carry their own ranges from unpickle) and caused a parallel test race for IL-imported types (shared BCL entities via FrameworkImportsCache + LazyWithContext caching first caller's range). Now uses entity.Range deterministically. Removed redundant TyparsNoRange.

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Warning

No PR link found in some release notes, please consider adding it.

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md	No current pull request URL (#19814) found, please consider adding it

[T-Gro]

🤖 AI-generated review

Findings (4 inline comments posted separately):

1. [API Surface — High] ResolveOverloadingForCall and UnifyUniqueOverloading (ConstraintSolver.fsi:268,282) gain a new objArgInfo parameter. These are public FCS API — this is a breaking change for downstream consumers. Consider threading via eContextInfo instead of adding a parameter, or document in release notes.

2. [Type System — Low] SolveTypeSubsumesType line 1661: csenvOuter passed to FindUniqueFeasibleSupertype recursive call is intentionally correct but contradicts the comment at 1530-1535 (''all recursive callsites use stripped context''). Add inline comment.

3. [Diagnostic Quality — Low] tryGetBindingName (CheckExpressions.fs:10441) is intentionally conservative. Worth a code comment noting Expr.Let wrapping won't be drilled through (fallback is safe).

4. [Diagnostic Quality — Low] SeeAlso condition (CompilerDiagnostics.fs:752) correctly checks both StartLine and EndLine. The adjacent ConstraintSolverNullnessWarningWithTypes (line 738) only checks StartLine — consider unifying for consistency.

[T-Gro]

Review Summary

Verdict: ✅ LGTM — Well-structured PR with correct implementation and strong test coverage.

The two changes (targeted dot-access nullness diagnostic + Entity.Typars cleanup) are cleanly separated. The stripMemberAccessOnNullableCtx / csenvOuter pattern correctly prevents context leakage while preserving the targeted diagnostic for the outer receiver check.

Verified Safe

• Entity.Typars → property: The range parameter was always the entity's own range for F# types, and IL-imported types get entity.Range set at import time. Fixes a real parallel compilation race.
• TypedTreePickle.fs: x.Typars ≡ x.entity_typars.Force(x.entity_range) — no binary compat risk.
• csenvOuter pattern in SolveTypeSubsumesType: Outer context correctly preserved only for same-tycon nullness check and supertype hierarchy recursion (FindUniqueFeasibleSupertype). Inner type-arg/tuple/fun recursion uses stripped context. No leak.
• TypesMustSubsume in ResolveOverloadingCore: Correctly uses csenv (with context) since obj-arg subsumption is the check that fires the dot-access warning. All other checks (instantiations, args, return) correctly use csenvNoCtx.
• stripTyEqns discipline: All TType_* matches operate on already-stripped types.

Suggestions (non-blocking)

1. API surface: ResolveOverloadingForCall and UnifyUniqueOverloading in ConstraintSolver.fsi gain a new objArgInfo: ObjArgInfo option parameter. These are public FCS API functions — downstream consumers (Ionide, FsAutoComplete) will need to update call sites. The release notes should mention this, or alternatively thread the info purely through eContextInfo on the constructed csenv (which the function already controls) to avoid changing these signatures.

2. Comment clarity at line ~1530: The comment says "all recursive callsites below" use stripped context, but line 1661 intentionally uses csenvOuter for FindUniqueFeasibleSupertype. A brief note explaining why that one is correct (outer-level subsumption traversal, not inner-type recursion) would prevent future confusion.

3. SeeAlso condition consistency: The new dot-access warning checks m.StartLine <> m2.StartLine || m.EndLine <> m2.EndLine while the adjacent ConstraintSolverNullnessWarningWithTypes only checks m.StartLine <> m2.StartLine. Consider unifying the condition.

Test Coverage

Comprehensive: generic receivers, extension methods, LINQ, mutables, compiler-generated vals, complex expressions, static calls, multi-line with SeeAlso, piped lambdas, out-of-scope paths (indexers, record fields, SRTP, anon records). The negative test (nullness off) and the boundary tests (e.g. nested nullable generic) are particularly valuable.

Nice work — the UX improvement for users is significant and the implementation is careful about not over-applying the new message.