Pass only narrow terminal-identifier range from name resolution

[T-Gro]

Narrow diagnostic ranges to terminal identifiers

Follow-up to #19505 per review feedback.

1. 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.

2. 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]

⚠️ 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]

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

[auduchinok]

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]

@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]

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]

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]

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]

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 🙂

[auduchinok]

Thanks!