Fix open declaration insertion in .fsx scripts after #r/#load directives (#16271)

[T-Gro]

Description

Fixes #16271

In .fsx scripts, #r and #load directives must precede any open declarations. Previously, the \FindNearestPointToInsertOpenDeclaration\ logic did not account for this constraint and could suggest inserting an \open\ before existing #r/#load\ directives, resulting in invalid script files.

Changes

• **\src/Compiler/Service/ServiceParsedInputOps.fs**: After computing the normal insertion point, if the file is a .fsx\ script, scan leading \HashDirective\ declarations and ensure the insertion point is placed after the last consecutive #r/#load\ at the top of the file.
• New test file: \ ests/FSharp.Compiler.Service.Tests/OpenDeclarationInsertionTests.fs** — covers scenarios with #r\ only, #r\ + #load\ combinations, and scripts without hash directives.

Testing

• Added focused unit tests verifying correct insertion position in various .fsx scenarios.
• Existing tests continue to pass.

[github-actions]

❗ 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:

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

[T-Gro]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[T-Gro]

Review of PR #19879 — Fix open declaration insertion in .fsx scripts

Overall the approach is sound: intercept after the normal insertion-point logic, scan for leading hash directives, and bump the position past them. A few issues to address:

Bug: Missing .fsscript extension handling

The PR only checks:

parsedInput.FileName.EndsWith(".fsx", StringComparison.OrdinalIgnoreCase)

But F# scripts can also use the .fsscript extension (see CompilerConfig.fs:44 — FSharpScriptFileSuffixes = [".fsscript"; ".fsx"]). The fix should either:

• Also check .fsscript, or
• Reuse the existing IsScript / FSharpScriptFileSuffixes infrastructure (preferred for consistency)

Questionable elif branch (untested)

elif lastHashLine = 0 && isAnonModule && ctx.Pos.Line > 1 then
    { ScopeKind = ScopeKind.TopModule; Pos = mkPos 1 0 }

This forces insertion at line 1 for .fsx files without hash directives when the normal logic picks a later line. But none of the tests exercise this branch (the test No r directives in fsx inserts at top has ctx.Pos.Line = 1 already, so it goes through else). This branch could interfere with correct open-grouping behavior when existing opens appear below a header comment:

// My script header
open System

let x = System.IO.File.ReadAllText "a"

Here the normal logic would correctly group the new open with the existing open System (line 2), but this branch would override it to line 1 (before the comment). Please either add a test proving this branch is needed, or remove it.

Test precision

The core test assertions use Assert.True(insertionPoint.Line >= 3) which is quite loose. If the logic were to (incorrectly) return line 100, the test would still pass. Consider using exact equality or at least a tighter range:

Assert.Equal(3, insertionPoint.Line)  // Exactly after the last #r on line 2

Minor: Release notes in 9.0.300.md

This PR targets main (which maps to 11.0.100). The entry in 9.0.300.md should probably only be added when/if this is backported to that servicing branch, unless repo conventions say otherwise.

---

The main fix logic is correct and well-motivated. Addressing the .fsscript gap and clarifying the elif branch would complete this nicely.

[T-Gro]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).