[xperiandri]

The "open namespace" code fix and open-adding completion found the insertion point by matching the text of a module header line, so several shapes produced code that does not compile:

• [<AutoOpen>] module Ns.Name on one line put the open above the module.
• A header without a blank line after it put the open below the first declaration.
• namespace Ns without a blank line after it split a type from its first member.

The insertion point now comes from the syntax tree. One existing test expectation moves by a line.

🤖 Generated with Claude Code

[github-actions]

✅ Release notes checked

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
`src/Compiler`	docs/release-notes/.FSharp.Compiler.Service/11.0.200.md
`vsintegration/src`	docs/release-notes/.VisualStudio/18.vNext.md

[xperiandri]

What this looked like before, and what it does now

Three shapes, each with the open the fix produced. The diagnostics below are from fsc on the "before" files, not from memory.

1. An attribute on the module's own line

[<AutoOpen>] module Ns.Helpers

let write () = Console.WriteLine "hi"

line.StartsWith "module" is false for that line, so the file read as an implicit module and the open went to the top of it — above the module declaration, where it cannot go:

open System                              // ← before: above the module declaration

[<AutoOpen>] module Ns.Helpers

let write () = Console.WriteLine "hi"

[<AutoOpen>] module Ns.Helpers

open System                              // ← after: inside the module

let write () = Console.WriteLine "hi"

2. No blank line under the header

module Ns.Helpers
let write () = Console.WriteLine "hi"

The arithmetic added two lines to reach "past the blank line under the header". With no blank line there, that landed past the first declaration, so the open came after the use of the name it was supposed to resolve — the error the fix was invoked on stayed exactly where it was:

module Ns.Helpers
let write () = Console.WriteLine "hi"    // ← before: still FS0039, the open is below it
open System

case2.fs(2,16): error FS0039: The value, namespace, type or module 'Console' is not defined.

module Ns.Helpers

open System                              // ← after

let write () = Console.WriteLine "hi"

3. namespace with no blank line under it

namespace Ns
type Reader() =
    member _.Read() = Console.ReadLine()

Same arithmetic, and here the two lines landed between the type header and its first member, splitting the type in half:

namespace Ns
type Reader() =
open System                              // ← before: inside the type definition

    member _.Read() = Console.ReadLine()

case3.fs(2,6): error FS0547: A type definition requires one or more members or other declarations.
case3.fs(5,5): error FS0010: Unexpected keyword 'member' in implementation file.

namespace Ns

open System                              // ← after

type Reader() =
    member _.Read() = Console.ReadLine()

Why the shapes above are the whole set

The three are not a list of spellings that were special-cased. InsertionContext.Pos now comes from the module's or namespace's leading keyword as the trivia records it, the identifier it introduces, and the = of a nested module — so what precedes the keyword on its line, and what follows the header, stop mattering. What is left in AdjustInsertionPoint is one cosmetic step: if the line under the header is blank, step over it, so the open joins the code rather than sitting in the gap.

[T-Gro]

🤖 🕵️ AI review — verify independently.

[T-Gro]

🤖🕵️ Please shorten the description using this guidance. Focus on the problem and why the change is needed, in simplified technical English. Leave the implementation inventory to the Files tab and retain necessary caveats.

[github-actions]

🔍 Tooling Safety Check — Affects-Design-Time
Affects-Design-Time: Changes IDE integration executed during design-time.

Generated by PR Tooling Safety Check · gpt56 1.7M · ◷

[Copilot]

Copilot review overview

🟡 Changes recommended

Single-line nested modules remain incorrectly handled, and newline preservation fails on unterminated final lines.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Anchor nearest-scope open insertion before first declaration · New
• Preserve file newline style for unterminated final lines · New

What changed in this PR

Moves open insertion placement from text matching to syntax-tree-derived positions shared by editor features.

Changes:

• Derives module and namespace insertion points from syntax ranges.
• Unifies code-fix and completion insertion logic.
• Adds regression tests and release notes.

File	Description
vsintegration/​tests/​FSharp.Editor.Tests/​CodeFixes/​AddOpenOnTopOnTests.fs	Adds top-level insertion regressions.
vsintegration/​tests/​FSharp.Editor.Tests/​CodeFixes/​AddOpenOnTopOffTests.fs	Tests attributed module insertion.
vsintegration/​src/​FSharp.Editor/​Common/​RoslynHelpers.fs	Centralizes open text changes.
vsintegration/​src/​FSharp.Editor/​CodeFixes/​AddOpenCodeFixProvider.fs	Uses the shared insertion helper.
tests/​FSharp.Compiler.Service.Tests/​OpenDeclarationInsertionTests.fs	Tests syntax-derived positions.
src/​Compiler/​Service/​ServiceParsedInputOps.fsi	Documents revised insertion semantics.
src/​Compiler/​Service/​ServiceParsedInputOps.fs	Computes positions from syntax ranges.
docs/​release-notes/​.VisualStudio/​18.vNext.md	Documents the editor fix.
docs/​release-notes/​.FSharp.Compiler.Service/​11.0.200.md	Documents FCS behavior changes.

[xperiandri]

Fixed in 777c4bd: a nested module whose first declaration shares the header's line is now entered at that declaration, so the fix breaks the line there and the open lands before the use. Covered by Fixes FS0039 for missing opens - nested module declared on one line and Open placed at the first declaration of a nested module declared on one line.

[xperiandri]

Fixed in 34c331e: only the last line can lack a line break, so the line above it supplies the file's; Environment.NewLine is left for a file of one line. Covered by Fixes FS0039 for missing opens - the open goes before a last line with no line break.

[T-Gro]

🤖 🕵️ Re-reviewed all recent changes as of dfe04ec; 1 finding

[T-Gro]

🤖🕵️ Nearest-scope opens enter the following module: open System leaves FS0039 on Console; accepting Obsolete completion throws ArgumentOutOfRangeException.

module Top
let x = Console.WriteLine 42
[<Obsolete>] module M = let y = 1

[xperiandri]

Fixed in dc46686: a nested module declared on one line is entered only by a use on its own line or below, and not when an attribute shares that line, so the open stays in the enclosing scope and the completion no longer composes its change from a position past the item. Covered by Open stays out of a nested module declared on one line that the use is not in, Fixes FS0039 for missing opens - the use is not in the nested module declared on one line and Completion that adds an open keeps it out of a nested module declared on one line.

[T-Gro]

🤖 🕵️ Re-reviewed all recent changes as of b42a8c7; LGTM

[T-Gro]

The diff is still way too big - apply the NoBloat instructions and CodeCompaction skill.

Especially the massive code comments would benefit not just with drastic reduction, but ideally with well named functions/arguments/bindings/types making the intention clear.

If a well named piece of code just tells what the comment says - delete the comment.

• Excluding 7 public API documentation lines, this diff still adds 34 implementation and test comment lines and 2609 comment chars.
• Comments bypass the type system and become stale maintenance state. Keep only durable public contracts; express implementation intent through names, functions, active patterns, discriminated unions, and types.

[xperiandri]

Compacted in 64ee01b (source) and 9e488ea (tests), behaviour unchanged. Added comment lines went from 41 to 7 (34 to 3 without the 4 public API doc lines, one of the 3 being the license header of the new test file; 2985 to 335 characters) and added lines from 478 to 315; what the comments said is in names now (lineAboveBody, useMayBeInModuleAttribute, blankLineAboveOpen, blankLineBelowOpen, textBeforeDeclaration), and a duplicated "Improve Find All References" bullet that a union merge had left in 18.vNext.md is removed.

The new tests are 7 methods instead of 14 over the same 17 cases, and the attribute-on-the-module-line case that was copied into both settings files is one theory run under both settings in AddOpenOnTopSharedTests.fs. Two one-line comments stay on purpose: why a TopModule position is reported as HashDirective, and that CompletionItem.WithSpan is obsolete, so the completion test takes the span from a completion context.

Test counts and results are the same as before the change: FCS OpenDeclarationInsertion 23 and AssemblyContent 5 (net472) pass, as do SurfaceArea and editor AddOpen 43/43, and the completion tests pass except the known fsiShouldTriggerCompletionInFsxFile failure, also on an Optimize=true build.

[T-Gro]

🤖🕵️ AI review — verify independently.

[T-Gro]

🤖🕵️ open System is inserted inside the header comment; FS0039 remains.

module Top (* header
*)
let x = Console.WriteLine 42