Pass only narrow terminal-identifier range from name resolution by T-Gro · Pull Request #19818 · dotnet/fsharp

T-Gro · 2026-05-26T18:01:40Z

Narrow diagnostic ranges to terminal identifiers

Follow-up to #19505 per review feedback.

Diagnostic ranges narrowed to terminal identifiers. Error/warning squiggles now point at the member name (Red) rather than the full qualified path (Color.Red). The narrow range is computed once in ComputeItemRange and threaded as mItemIdent through all Tc*ItemThen handlers.
TypedTree expression ranges preserved. Expression construction, type unification, PDB sequence points and debug stepping continue to use the wide mItem range — unaffected.

Only code with qualified identifiers (Module.Member, obj.Property, Namespace.Type.Member) sees narrower squiggles. Single-identifier code is unchanged.

Unchanged: IDE hover · go-to-definition · find-all-references · IL emission · PDB sequence points · binary compatibility. No new/removed diagnostics, no severity changes.

Baseline changes — 24 ranges across 8 test files

All strictly narrower (start column shifts right, end column unchanged):

Pattern	Example	Diagnostic
`rec.field`	`r1.foo` → `foo`	FS1096 field not accessible, FS0005 not mutable
`obj.Property`	`this.GetInit` → `GetInit`	FS0810 init-only / cannot set, FS0807 not readable
`Type.Member`	`Color.Red` → `Red`	FS0101/FS0044 obsolete
`Class.Field`	`Class.ObsoleteField` → `ObsoleteField`	FS0044/FS0101 obsolete
`Class.Event`	`Class.ObsoleteEvent` → `ObsoleteEvent`	FS0044/FS0101 obsolete
`_.id` (dot-lambda)	`_.id` → `id`	FS0812 syntax form
`M.Svc.OldMethod`	→ `OldMethod`	FS0044 obsolete (overload resolution)

github-actions · 2026-05-26T18:02:53Z

⚠️ Release notes required, but author opted out

Warning

Author opted out of release notes, check is disabled for this pull request.
cc @dotnet/fsharp-team-msft

T-Gro · 2026-05-28T12:44:42Z

(this adds on a recent PR, release notes were part of it already)

auduchinok · 2026-05-28T12:51:08Z

            let resolvesAsExpr =
                match nameResolutionResult with
-                | Result (tinstEnclosing, item, mItem, mItemIdent, rest, afterRes)
+                | Result (tinstEnclosing, item, mItem, rest, afterRes)


Can this be reverted to pre-#19505, so we don't reconstruct res argument below?

auduchinok · 2026-05-28T12:52:13Z

    let ad = env.eAccessRights
    let typeNameResInfo = GetLongIdentTypeNameInfo delayed
-    let (tinstEnclosing, item, mItem, mItemIdent, rest, afterResolution) =
+    let (tinstEnclosing, item, mItem, rest, afterResolution) =


Can this be reverted to pre-#19505?

auduchinok · 2026-05-28T12:54:29Z

Can we remove this error post-processing?

auduchinok · 2026-05-28T12:55:53Z

    match ResolveExprLongIdent sink ncenv wholem ad nenv typeNameResInfo lid maybeAppliedArgExpr with 
    | Exception e -> Exception e 
    | Result (tinstEnclosing, item1, rest) ->
    let itemRange, itemIdentRange = ComputeItemRange wholem lid rest


Can ComputeItemRange return the single range, as in pre-#19505?

They are both needed - the other goes into sink(s) for IDE functions.

auduchinok · 2026-05-28T12:58:22Z

PDB sequence points: 1
Debugger highlights CurrentDirectory instead of Environment.CurrentDirectory

This is unexpected change and adds inconsistency with the breakpoints that tooling uses. We should try to keep the debugger info as is here. I think sequence points should use the whole expression ranges? Or do they rely on typed tree ranges that are now narrowed down?

T-Gro · 2026-05-28T13:50:22Z

@auduchinok : It comes from the range on Expr node in TypedTree.
And then it makes its way into EmitDebugPoint from it.

When stepping, why do you think it's wrong to highlight only the narrow item? Or is there another concern?

auduchinok · 2026-05-28T14:09:16Z

When stepping, why do you think it's wrong to highlight only the narrow item? Or is there another concern?

The debugger sequence points normally cover the whole "statements" that include complete calls, arguments, and so on. Narrowing it here would create inconsistency in debugger experience. It would also be inconsistent with breakpoint ranges we provide in the tooling.

@auduchinok : It comes from the range on Expr node in TypedTree.

A guess: could it be because mItem was used somewhere instead of mWhole when creating Expr? Previously these range two could be the same and now mItem is narrower.

T-Gro · 2026-05-28T14:16:32Z

The narrowing only strips module/namespace/type prefixes from the sequence point:

System.Environment.CurrentDirectory → debug highlight on just CurrentDirectory
Option.None → just None
MyModule.myValue → just myValue

But System.Console.WriteLine("hello") still gets a sequence point covering the entire call including "hello", because mWholeExpr unions the method range with the argument ranges.

So I think OK?

auduchinok · 2026-05-28T14:22:21Z

I really think we should not change sequence point ranges. I think we have to stay consistent with the rest of the language and C# and other languages debugging experience. Unfortunately, it seems we have to pass the two ranges to places like TcItemThen to use them in the typed tree expressions, after all.

auduchinok · 2026-05-28T17:31:29Z

I also think we should keep the typed tree ranges closer to the syntax tree, so if some IDE feature work with this tree, they could also rely on these ranges. And we've been working hard on making syntax tree ranges correct 🙂

Simplifies the type-checking pipeline by removing the wide (module-qualified) range from resolved-item returns. Only the narrow terminal-identifier range flows through TcItemThen and downstream functions. Affected features: error/warning squiggles now point at the member name (e.g. 'Member') rather than the full qualified path ('Module.Member'). IDE hover, go-to-definition, and find-all-references use the narrow range from NameResolution sinks (unchanged). No impact on IL emission or binary compatibility — all changed APIs are internal. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Revert to pre-#19505 patterns: use '_ as res' in TcNameOfExpr and pass-through binding in TcLongIdentThen instead of destructuring and reconstructing the 5-tuple. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ow mItemIdent for diagnostics Restore itemRange (wide) alongside itemIdentRange (narrow) in name resolution return tuples. Thread mItemIdent through all TcItemThen handlers for attribute checks, error messages, and diagnostic squigglies while keeping mItem for expression construction and PDB sequence points. Revert test baselines for type unification and expression-range diagnostics to their original wide ranges. Update baselines for property/field access errors and other handler-specific diagnostics to their new narrow ranges. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

- CheckRecdFieldMutation in static field path: mItem -> mItemIdent (parity with instance path) - nonStandardEventError in TcEventItemThen: mItem -> mItemIdent (parity with sibling event diagnostics) - Restore section comments in TcLookupItemThen for scanability Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

- Rename mDiag -> mItemIdent in ApplyUnionCaseOrExn for naming consistency - Add clarifying comment at m m call site in TcUnionCaseOrExnField - Restore explanatory comments for duplicate diagnostics in OverloadResolutionErrorRangeTests Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

auduchinok · 2026-06-02T14:40:38Z

Thanks!

The fsharp suite migrated tests (neg10, neg15, neg17, neg90, neg91) use .bsl baselines that were not updated for the narrowed mItemIdent ranges. - neg10: Property 'not readable' diagnostics now point at property name - neg15: Union case/field access errors point at terminal identifier - neg17: Union case type accessibility error points at case name - neg90: RequireQualifiedAccess deprecation points at case name - neg91: Value accessibility/obsolete errors on assignment point at value Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

T-Gro requested a review from a team as a code owner May 26, 2026 18:01

github-project-automation Bot added this to F# Compiler and Tooling May 26, 2026

github-project-automation Bot moved this to New in F# Compiler and Tooling May 26, 2026

github-actions Bot added the AI-Tooling-Check-Bypassed Tooling check: non-fork PR, not diff-analyzed label May 26, 2026

T-Gro force-pushed the narrow-range-only branch from 45a6bcf to 37c3c9e Compare May 27, 2026 10:24

T-Gro requested a review from abonie May 27, 2026 13:28

T-Gro force-pushed the narrow-range-only branch 2 times, most recently from 45a6bcf to 4f5da6f Compare May 28, 2026 08:45

T-Gro requested a review from auduchinok May 28, 2026 12:44

T-Gro added the NO_RELEASE_NOTES Label for pull requests which signals, that user opted-out of providing release notes label May 28, 2026

auduchinok reviewed May 28, 2026

View reviewed changes

T-Gro force-pushed the narrow-range-only branch from 4f5da6f to e779dee Compare May 28, 2026 13:22

T-Gro added the AI-reviewed PR reviewed by AI review council label Jun 2, 2026

This comment was marked as off-topic.

Sign in to view

T-Gro and others added 6 commits June 2, 2026 16:31

Trim .fsi doc comments and update test baselines for narrowed ranges

72acb18

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

T-Gro force-pushed the narrow-range-only branch from 466c779 to bc4ed5a Compare June 2, 2026 14:31

auduchinok approved these changes Jun 2, 2026

View reviewed changes

T-Gro mentioned this pull request Jun 2, 2026

[feature/net11-scouting] Update dependencies from dotnet/arcade #19874

Merged

Copilot and others added 2 commits June 3, 2026 12:55

Merge remote-tracking branch 'origin/main' into narrow-range-only

418663d

Conversation

T-Gro commented May 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Narrow diagnostic ranges to terminal identifiers

Baseline changes — 24 ranges across 8 test files

Uh oh!

github-actions Bot commented May 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ Release notes required, but author opted out

Uh oh!

T-Gro commented May 28, 2026

Uh oh!

auduchinok May 28, 2026

Choose a reason for hiding this comment

Uh oh!

T-Gro May 28, 2026

Choose a reason for hiding this comment

Uh oh!

auduchinok May 28, 2026

Choose a reason for hiding this comment

Uh oh!

T-Gro May 28, 2026

Choose a reason for hiding this comment

Uh oh!

auduchinok May 28, 2026

Choose a reason for hiding this comment

Uh oh!

auduchinok May 28, 2026

Choose a reason for hiding this comment

Uh oh!

T-Gro May 28, 2026

Choose a reason for hiding this comment

Uh oh!

auduchinok commented May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

T-Gro commented May 28, 2026

Uh oh!

auduchinok commented May 28, 2026

Uh oh!

T-Gro commented May 28, 2026

Uh oh!

auduchinok commented May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

auduchinok commented May 28, 2026

Uh oh!

This comment was marked as off-topic.

Uh oh!

This comment was marked as off-topic.

Uh oh!

auduchinok commented Jun 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

T-Gro commented May 26, 2026 •

edited

Loading

github-actions Bot commented May 26, 2026 •

edited

Loading

auduchinok commented May 28, 2026 •

edited

Loading

auduchinok commented May 28, 2026 •

edited

Loading