Fix double Dispose in use bindings with as patterns (#12300)

[T-Gro]

Summary

Fixes #12300 — use a as b = d (and use b = a where a is already use-bound) previously generated multiple Dispose calls for the same underlying object.

Root Cause

The compiler emitted one Dispose per name introduced by a use pattern. With as patterns (use a as b = d) or rebinding (use b = a), each alias triggered its own cleanup, causing the same IDisposable to be disposed multiple times.

Fix

Two scenarios are addressed in CheckExpressions.fs:

Scenario A — use a as b = d: Emit exactly one Dispose call on the canonical patternInputTmp value (the initial tmp that holds the bound expression) regardless of how many names the as pattern introduces.

Scenario B — use b = a where a is use-bound: Detect when the RHS of a use binding is a simple reference to an already use-bound value and skip the redundant cleanup. The outer use already owns the Dispose.

The detection for Scenario B uses a new eUseBoundValStamps set on the type-checking environment to track which values are known use-bound.

Tests

Added UseBindingDisposalTests.fs with 6 tests covering:

• use a as b = d disposes once
• use b = a (rebind of use-bound) disposes once
• Normal use still disposes
• Discarded use _ = d still disposes
• Two independent use bindings each dispose
• Triple alias use a as b as c = d disposes once

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md

[T-Gro]

Review: Fix double Dispose in use bindings with as patterns (#12300)

Verdict: Approve ✅

Summary

This PR correctly fixes issue #12300 where use bindings with as patterns (e.g., use a as b = d) or rebinding an existing use-bound value (use b = a) caused double Dispose() calls. The fix is minimal, well-scoped, and handles both scenarios cleanly.

Analysis

Scenario A (as-pattern): The original code called Dispose on every val introduced by the pattern via List.foldBack. Since use a as b = d introduces both a and b pointing to the same object, this meant double disposal. The fix correctly narrows to a single Dispose on patternInputTmp — the canonical value holding the bound expression.

Scenario B (rebinding): use b = a where a is already use-bound. The fix introduces eUseBoundValStamps to track use-bound vals and checks if the RHS is a direct reference to one. If so, the inner use skips its cleanup, deferring to the outer use. This is correct — the env (not envInner) is used for the alias check, so it only sees vals from enclosing scopes, while the current binding's vals are added to envInner for downstream visibility.

Edge cases handled correctly:

• use _ = expr still disposes (wildcard uses patternInputTmp)
• use b = f(a) where a is use-bound — NOT suppressed (only direct val refs are detected)
• Nested scopes: stamps are part of TcEnv which scopes correctly
• let b = a; use c = b — NOT suppressed (intermediate let doesn't add to stamps)

Code Quality

• Good use of Set<Stamp> (immutable, no concurrency concerns)
• Performance impact is negligible — the set grows only with use bindings in scope
• The local stripTyLambdas is appropriate since no equivalent utility exists at this layer (the one in EraseClosures.fs has a different signature/purpose)
• Comments clearly explain the rationale and reference the issue

Tests

Comprehensive coverage of:

• use a as b = d (single dispose)
• use b = a where a is use-bound (single dispose)
• Normal use (still works)
• Discarded use _ = d (still disposes)
• Independent use bindings (each disposes)
• Triple alias use a as b as c = d (single dispose)

Minor Observations (non-blocking)

1. The .fs doc comment says /// See .fsi. — this is fine as a cross-reference pattern but slightly unusual in this codebase where most fields have inline docs in both files.

2. Consider whether the stripTyLambdas + Expr.Val check should also handle Expr.App(Expr.Val(...), ...) patterns for upcasts (e.g., use b = (a :> IDisposable)). Currently this would NOT suppress the duplicate dispose. This may be an acceptable limitation for a follow-up if it's ever reported.

Overall, this is a clean, correct fix with excellent test coverage. Nice work! 🎉

[abonie]

Should perhaps add a case like
| Expr.Op(TOp.Coerce, _, [inner], _) -> stripCoerceAndTyLambdas inner
otherwise something like (idk how common this is)
use b = (a :> System.IDisposable)
will still "double Dispose"

[abonie]

If this is too contrived, feel free to skip this comment