Skip to content

Fix lost source range for empty-bodied computation expressions in pipelines (#19550)#19849

Open
T-Gro wants to merge 2 commits into
mainfrom
fix/issue-19550
Open

Fix lost source range for empty-bodied computation expressions in pipelines (#19550)#19849
T-Gro wants to merge 2 commits into
mainfrom
fix/issue-19550

Conversation

@T-Gro
Copy link
Copy Markdown
Member

@T-Gro T-Gro commented May 28, 2026

Summary

Fixes #19550

When a computation expression with an empty body (e.g. foo {}) is used in a pipeline, the synthesized Zero() call was given range0 (i.e. unknown(1,1)) instead of the actual source location. This caused type mismatch errors to report nonsensical locations and LSP diagnostics to be lost.

Changes

  • CheckExpressions.fs: Pass mExprAndArg (the full App range) instead of mLeftExpr as the mWhole parameter to TcComputationExpression, so the synthesized Zero() call receives a meaningful range when the CE body is empty.
  • CheckComputationExpressions.fs: In the SynExpr.ImplicitZero translation, fall back to ceenv.mWhole when the incoming range is range0, defensively preventing zero-ranged synthesized calls from reaching codegen/diagnostics.
  • SemanticClassification.fs / ConstraintSolver.fs: Minor cleanup in the same area.

Tests

Added tests/FSharp.Compiler.ComponentTests/Language/CE_PipelineRange19550.fs with comprehensive tests covering:

  • Empty CE in forward pipe, backward pipe, composition, and direct application
  • Nested pipelines and multi-step pipelines
  • Verification that error ranges point to the correct source location

Release Notes

Added entry in docs/release-notes/.FSharp.Compiler.Service/11.0.100.md.

Copilot and others added 2 commits May 28, 2026 15:53
…elines (#19550)

- Pass mExprAndArg (full App range) instead of mLeftExpr as mWhole to TcComputationExpression so that the synthesized Zero() call has a meaningful range when the CE body is empty.

- Fall back to ceenv.mWhole inside the SynExpr.ImplicitZero translation when the incoming range is range0, defensively preventing zero-ranged synthesized calls from reaching codegen / diagnostics.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Adds the CE_PipelineRange19550 test file (registered in the ComponentTests fsproj) and a release-notes bullet in 11.0.100.md.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@github-actions
Copy link
Copy Markdown
Contributor

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

@github-actions github-actions Bot added the AI-Tooling-Check-Bypassed Tooling check: non-fork PR, not diff-analyzed label May 28, 2026
| _ -> error (Error(FSComp.SR.tcRequireBuilderMethod "Zero", m))

Some(translatedCtxt (mkSynCall "Zero" m [] ceenv.builderValName))
let mCall = if equals m range0 then ceenv.mWhole else m
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we locate the place where the wrong range was set in the first place?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI-Tooling-Check-Bypassed Tooling check: non-fork PR, not diff-analyzed

Projects

Status: New

Development

Successfully merging this pull request may close these issues.

Source location gets lost when a type mismatch happens on computation expression

2 participants