Fix let-in scoping in light syntax via LexFilter change

[Copilot]

Addresses the long-standing issue where let ... in with an explicit in keyword in indentation-sensitive F# code causes the parser to greedily capture all subsequent lines as part of the let body, leading to unexpected scoping behavior.

Problem

do
    let x = 1 in x + 1
    x  // incorrectly becomes part of the let body

The parser creates LetOrUse(let x = 1, Sequential(x + 1, x)) instead of the expected Sequential(LetOrUse(let x = 1, x + 1), x), causing x on the second line to resolve to the local binding rather than the outer scope.

Changes Made

• New language feature: Added LanguageFeature.WarnOnLetInSequenceExpression in LanguageFeatures.fs/fsi, gated at F# 11.0
• LexFilter change: In LexFilter.fs, when blockLet=true and an explicit IN token is encountered with the body expression starting on the same line as in, a new CtxtSeqBlock with AddBlockEnd is pushed. This creates an OBLOCKBEGIN/OBLOCKEND wrapper around the body, limiting its scope via indentation — tokens on the next line at a lower column are offside and close the block, preventing greedy capture.
• Intentional multi-line preserved: When the body starts on the next line after in (e.g., chained let ... in / let! ... in / and! patterns), standard behavior is preserved.
• Regression tests: 4 tests in WarnExpressionTests.fs covering scoping in do blocks, function bodies, no change for single-line usage, and no change on older language versions
• SyntaxTree baseline: 1 baseline updated for minor range change
• Release notes: Documented in 11.0.100.md

Testing

• ✅ All 4 regression tests pass
• ✅ All 1042 ParseFile SyntaxTree tests pass (1 baseline updated)
• ✅ All 2129 FSharp.Compiler.Service tests pass
• ✅ All 524 ErrorMessages tests pass
• ✅ All 630 BasicGrammarElements tests pass
• ✅ All 776 Language tests pass
• ✅ SurfaceAreaTest passes
• ✅ CodeQL reports no security issues

---

💬 Send tasks to Copilot coding agent from Slack and Teams to turn conversations into code. Copilot posts an update in your thread when it's finished.

[T-Gro]

@copilot : Try again

[T-Gro]

@copilot : Try again.

[abonie]

@copilot Try again

[Copilot]

@copilot Try again

Implemented in 4c00982 and 6259b63. Added warning FS3885 (gated behind LanguageFeature.WarnOnLetInSequenceExpression at F# 11.0) that fires when let ... in with an explicit in keyword has a body that extends to subsequent lines — the common pitfall from issue #7091 where the parser greedily captures all subsequent lines as part of the let body.

Changes:

• New LanguageFeature.WarnOnLetInSequenceExpression in LanguageFeatures.fs/fsi
• Warning FS3885 message in FSComp.txt
• Detection in CheckExpressions.fs: checks for explicit in keyword + Sequential body extending past the in line
• 4 regression tests (warning in do block, warning in function body, no warning for single-line let-in, no warning without preview langversion)
• Release notes

All 520 ErrorMessages tests and 630 BasicGrammar tests pass.

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
LanguageFeatures.fsi	docs/release-notes/.Language/preview.md

[auduchinok]

@T-Gro Have you considered changing how this is handled by LexFilter? Can we detect a new line there and drop the let context?

[T-Gro]

I think I would not be able to avoid breaking changes? A warning can still be silenced, a different decision in LexFilter would affect rest of the compilation process as well.

OR you think this can be done safely?

[auduchinok]

I'd vote for a breaking change here. Similar to various cases in fsharp/fslang-suggestions#1273, I think there should be not many cases where such code was written intentionally and could be compiled successfully.

The initially reported issue comes from brute-force checking of various cases to test, not from real code 🙂

[T-Gro]

@copilot :

Lets try in a separate commit to implement a LexFilter change for let-in (as suggested by #19501 (comment) and by #19501 (comment) ). I.e. moving the logic from a type checking warning, to a lexfilter logical change and error.

I first want to see how it will look like.
You will need to run and adjust tests as well (I assume a lot of parser / SyntaxTree tests might need an update).

Do the work and the commit so that I can asses the impact.

[Martin521]

As far I understand it, it applies for cases where the indentation matches. The example there doesn't include the in part which is the key part here.

15.1.9 (exceptions to the rules) doesn't include the case that is being fixed here.

I think the spec is very clear here. The rule applies to SeqBlocks and that is what we have here. And of course it does not need to be listed under exceptions because it is no exception.

Beyond the spec discussion, I believe this PR would introduce a gross inconsistency as shown in the comment above and should be rejected even on this reason alone.

[auduchinok]

in does start a new context, but not a new SeqBlock.

Hm, then maybe starting a SeqBlock indeed would be a better fix for this inconsistency, thanks. We would need to check if it could cause any other unexpected changes, though.

[Martin521]

Hm, then maybe starting a SeqBlock indeed would be a better fix for this inconsistency, thanks. We would need to check if it could cause any other unexpected changes, though.

It is not an inconsistency. A "fix" would create an inconsistency. For good reasons the spec and the current compiler don't start a SeqBlock at in. And I don't see a reason to change that.

[Martin521]

@T-Gro
What is your view on my concerns?

[T-Gro]

@T-Gro What is your view on my concerns?

I do not want to rush this for sure.

The original issue #7741 is in my view very legit - it simply is not what is expected by the casual reader.

I did start with a warning first for the specific coding pattern in this PR (i.e. not a parser change, but a typechecking detection).

You are right with the behavior w.r.t to the spec.

At the same time, the code shown at #7741 is something not to be encouraged - I would definitely not like keeping the status quo here.

[Martin521]

@T-Gro Thanks!
The spec can be changed, of course. I just want to make sure that the whole picture is seen and discussed beforehand.
Here are some more considerations.

When the "lightweight syntax" was introduced a LONG time ago, it was designed (I am quoting the spec) as "a conservative extension of the explicit language syntax, in the sense that it simply lets you leave out certain tokens". It was not a fundamental change of the syntax. The main rules are

• In expression blocks, NEWLINE can replace the in in value or function definition expressions and can replace the ; in sequential execution expressions.
• In top-level expressions, NEWLINE can replace the ;;.
• At the end of expression blocks, done can be ommitted.

This does not change other aspects of the syntax, like precedence.
This means that the following three expressions are equivalent:

let x = 1 in printfn $"{x}"; printfn $"{x}"

let x = 1 in printfn $"{x}"
printfn $"{x}"

let x = 1
printfn $"{x}"
printfn $"{x}"

Changing the meaning of the second one (as this PR does) would make the language inconsistent and would make explaining the (already complicated) "light syntax" rules even harder.

Now, while most of the "old" constructs (line ;;, done, begin - end) are hardly seen any more in F# repos, both in and ; (for sequential execution expressions) are still in use. Mostly by people (like myself) who value conciseness. But perhaps it is time to prepare to abandon them like other ML heritage in the F# syntax. Therefore, I believe that adding a warning (as recommended by @dsyme) is a good step.

[auduchinok]

Changing the meaning of the second one (as this PR does) would make the language inconsistent and would make explaining the (already complicated) "light syntax" rules even harder.

I respectfully disagree. This would make it easier to explain it, because the main light syntax "things have to have the same indentation" rule would be applied in a more consistent way by not allowing the sequence expression body to have different indents.

[T-Gro]

@Martin521 :

I think it's fair to say that the extension has become the default - the rules should accommodate for that, even though I totally see why the spec is historically layered in a different way.

For the middle example - it feels more consistent with other rules if it would be written like this (accepting a spec change and parser change)

let x = 1 in printfn $"{x}"
             printfn $"{x}"

(following that ; is optional in expr1;expr2 if The expression expr2 occurs on a subsequent line that starts in the same column as expr1. )

[Martin521]

I am still not completely convinced, but it seems I am overruled and I accept that.
I just would like to see a small RFC for the change. It should explain how the three examples (or similar ones) are parsed a) in an expression block and b) as declarations. Note that compiler and spec today treat 5 of those 6 cases as "value definition expression" that have a sequence expression (the two printfn expressions) as body while the last example directly in a module is parsed as three "module value definition" declarations (one for the let and two for the do printfn lines). We should know how these six cases will be handled after the change.

[Martin521]

As a separate question: how do you feel about phasing out in altogether?

[auduchinok]

As a separate question: how do you feel about phasing out in altogether?

It seems it's often used in one-line expressions inside lambdas and similar places, so we probably shouldn't remove it.