Fix semantic classification errors for generics, slices, CEs, and open type by T-Gro · Pull Request #19939 · dotnet/fsharp

T-Gro · 2026-06-12T17:55:35Z

Fixes#19905

Type.Method<int>() / new T<args>(...) / T<args>.M(...) no longer classify <…> as Function/Type; span narrows to the identifier.
list[0..] trailing ] no longer classified as Function.
CE builder name inside [ for .. do builder { } ] classified as ComputationExpression, not Value.
open type T no longer always reported as unused.

github-actions · 2026-06-12T17:56:31Z

❗ Release notes required

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

✅ 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 (#19939) found, please consider adding it

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

T-Gro

AI-generated review (Claude / expert-reviewer agent). Findings posted as inline comments — please apply human judgement before acting.

T-Gro

🤖 AI-generated review (Claude / expert-reviewer agent) — complementary to T-Gro's earlier pass. Findings posted as inline comments; please apply human judgement before acting.

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

…ate decl PR #19813 suppressed a narrow synthesized Invoke/BeginInvoke/EndInvoke classification in a delegate declaration via a one-directional rangeContainsRange check inside the Item.MethodGroup arm. A second wide-range entry whose range covers the whole 'delegate of . -> .' clause still slipped through because the parser-synthesized SynValSig for the delegate's abstract slot is resolved as Item.Value vref (not Item.MethodGroup), with the val's idRange covering the entire `delegate of x: int * y: int -> int` clause (this is the parser's lhs range of the DELEGATE OF topType production used both for the SynIdent and the SynValSig itself). Add a targeted suppression in the Item.Value vref arm (vref.IsMember branch): when the val is a dispatch slot named Invoke/BeginInvoke/EndInvoke whose MemberApparentEntity is an F# delegate tycon, do not emit a Method classification. This precisely matches the parser-synthesized abstract slot only - real call sites like `d.Invoke(42)` resolve as Item.MethodGroup which is handled by the existing arm and is unaffected. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…od/ctor calls In TcMethodItemThen and TcCtorItemThen, the DelayedTypeApp branches were calling CallNameResolutionSink / CallExprHasTypeSink with the merged 'mExprAndTypeArgs' / 'mExprAndArg' range instead of the identifier range 'mItem'. The classifier then attached one wide Method/DisposableType classification covering the type-argument list (items 3 and 6) and even the constructor argument list (item 4), drowning out the punctuation/lambda that should remain neutral. Use 'mItem' - the same range the type-provider fast path already uses in TcMethodItemThen. The Types CNR in TcTypeItemThen is intentionally left alone (the qualified-name case fixed in #18009 / #19800 relies on it). For items 4 and 6 the wide CNR is registered by upstream paths (ForNewConstructors in TcCtorCall and CallMethodGroupNameResolutionSink in ResolveExprDotLongIdentAndComputeRange) that must keep the wide range for find-references and goto-definition. Add classification-only narrowing in SemanticClassification.fs based on the item's DisplayNameCore length: - Method/Property: narrow to the last `displayName.Length` characters of the CNR range (trailing identifier, e.g. `Start` in `MailboxProcessor<int>.Start`). - CtorGroup: narrow to the leading `displayName.Length` characters (type name comes first in `new T<typeArgs>(...)`). This leaves the CapturedNameResolutions untouched so symbol uses, tooltips and navigation continue to use the wide ranges they always did. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The existing takeCustomBuilder dedup only handled the exactly-2-CNR group (one Item.Value + one Item.CustomBuilder at the same range). Inside a list / array comprehension the captured name resolutions for the builder identifier can include more than two CNRs at the same range, and the fall-through path returned them all, leaving the Item.Value to dominate the classifier output and color the builder identifier as a plain Value. Generalize: at any group of CNRs that share a range, if at least one is Item.CustomBuilder, keep only the CustomBuilder ones. This preserves the existing 2-CNR behavior and additionally fixes the comprehension case. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

For 'xs[0..]' (and the set-slice variants) on nominal types, TcIndexingThen synthesizes a DelayedDotLookup for GetSlice/SetSlice/Item. The synthesized identifier carried mWholeExpr (the whole bracketed expression including ']'), which the resolver then turned into a Method-classification CNR that the editor showed on the closing ']'. Syntheticize the identifier range and the DelayedDotLookup range so the CNR is filtered out by the existing IsSynthetic check in the resolutions pipeline. The DelayedApp ranges are left intact so error diagnostics keep their real ranges. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Adds a regression guard for the case where `open type X` is used purely via an unqualified static-member call (e.g. `Button ...` after `open type Helpers.View`). On HEAD, UnusedOpens already detects this as used; this test pins the behavior so future refactors of ServiceAnalysis.fs cannot silently regress it. The existing enum-only coverage in `Unused opens in non rec module smoke test 1` did not exercise the class-with-static-members path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

T-Gro · 2026-06-17T18:56:18Z

Superseded by #19960 (rebased).

T-Gro requested a review from a team as a code owner June 12, 2026 17:55

github-project-automationBot added this to F# Compiler and Tooling Jun 12, 2026

github-project-automationBot moved this to New in F# Compiler and Tooling Jun 12, 2026

T-Gro pushed a commit that referenced this pull request Jun 12, 2026
Add PR#19939links to release notes for classification fixes
81d06ef
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

github-actionsBot added the AI-Tooling-Check-Bypassed Tooling check: non-fork PR, not diff-analyzed label Jun 12, 2026

T-Gro commented Jun 15, 2026
View reviewed changes

Comment threadsrc/Compiler/Service/ServiceAnalysis.fs
Comment threadsrc/Compiler/Service/SemanticClassification.fs Outdated
Comment threadsrc/Compiler/Checking/Expressions/CheckExpressions.fs Outdated

auduchinok reviewed Jun 15, 2026
View reviewed changes

T-Gro commented Jun 15, 2026
View reviewed changes

Comment threadsrc/Compiler/Checking/Expressions/CheckExpressions.fs
Comment threadsrc/Compiler/Checking/Expressions/CheckExpressions.fs
Comment threadsrc/Compiler/Checking/Expressions/CheckExpressions.fs
Comment threadsrc/Compiler/Service/SemanticClassification.fs Outdated

T-Gro force-pushed the fix/issue-19905 branch from 81d06ef to 4399ff3Compare June 15, 2026 19:13

T-Gro pushed a commit that referenced this pull request Jun 15, 2026
Add PR#19939links to release notes for classification fixes
f4a2da9
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

T-Gro force-pushed the fix/issue-19905 branch from 68f5c84 to 59d9b23Compare June 16, 2026 12:03

Copilotand others added 5 commits June 17, 2026 10:04

T-Gro force-pushed the fix/issue-19905 branch from d24075e to a728cacCompare June 17, 2026 18:55

T-Gro closed this Jun 17, 2026

github-project-automationBot moved this from New to Done in F# Compiler and Tooling Jun 17, 2026

Navigation Menu

Uh oh!

Fix semantic classification errors for generics, slices, CEs, and open type - #19939

Fix semantic classification errors for generics, slices, CEs, and open type#19939
T-Gro wants to merge 5 commits into
mainfrom
fix/issue-19905

T-Gro commented Jun 12, 2026

Uh oh!

github-actionsBot commented Jun 12, 2026•
edited
Loading

Uh oh!

T-Gro left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

T-Gro left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

T-Gro commented Jun 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

T-Gro commented Jun 12, 2026

Uh oh!

github-actionsBot commented Jun 12, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

❗ Release notes required

Uh oh!

T-Gro left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

T-Gro left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

T-Gro commented Jun 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

github-actionsBot commented Jun 12, 2026•
edited
Loading