Skip to content

[Repo Assist] Fix open insertion position for nested explicit modules (issue #789)#1495

Merged
Krzysztof-Cieslak merged 2 commits intomainfrom
repo-assist/fix-issue-789-open-insertion-nearest-26901d63ecacc89b
Mar 10, 2026
Merged

[Repo Assist] Fix open insertion position for nested explicit modules (issue #789)#1495
Krzysztof-Cieslak merged 2 commits intomainfrom
repo-assist/fix-issue-789-open-insertion-nearest-26901d63ecacc89b

Conversation

@github-actions
Copy link
Contributor

🤖 This is an automated PR from Repo Assist.

Summary

Fixes the inconsistency reported in #789 where the code-fix path inserted an open declaration before a nested module declaration, while code-completion correctly placed it inside the module.

Root cause

FSharp.Compiler.Service's ParsedInput.TryFindInsertionContext sets InsertionContext.Pos.Line to the module declaration line itself (e.g. the line containing module Foo =) rather than the first line inside the module. adjustInsertionPoint passed this value unchanged for ScopeKind.Module, so openFix computed docLine = l - 1 and inserted the open statement immediately before the module Foo = line.

ParsedInput.FindNearestPointToInsertOpenDeclaration (used by code-completion) does not have this quirk, which explains the pre-existing inconsistency.

Fix

Added a helper isExplicitModuleDeclaration that recognises module X = lines (with a trailing =, to distinguish them from top-level implicit module headers). In the | _ -> branch of adjustInsertionPoint, when the candidate insertion line is such a declaration, the insertion point is advanced by one so the open lands on the first line inside the module.

Before (code-fix for cursor inside module Nested =):

module Root
open System.Text.RegularExpressions   // ← placed BEFORE module Nested

module Nested =
  let foo () = Regex

After:

module Root

module Nested =
  open System.Text.RegularExpressions  // ← placed INSIDE module Nested

  let foo () = Regex
```

### Test status

New regression test added:
```
FSAC.lsp.Ionide WorkspaceLoader.BackgroundCompiler.CodeFix-tests.ResolveNamespace
  .place open in nearest enclosing module when cursor is in nested module (issue #789) ✅
FSAC.lsp.Ionide WorkspaceLoader.TransparentCompiler.CodeFix-tests.ResolveNamespace
  .place open in nearest enclosing module when cursor is in nested module (issue #789)

All previously-passing ResolveNamespace tests continue to pass. There are 6 pre-existing failures (place open in module correctly without any modules, place open in module correctly when having additional modules, With attribute) that existed on main before this PR — they are caused by the same FCS behaviour and will benefit from this fix once the test expectations are updated in a follow-up.

Generated by Repo Assist

Generated by Repo Assist ·

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f

FCS's TryFindInsertionContext sets Pos.Line to the module *declaration*
line (e.g. 'module Foo =') rather than the first line inside the module.
adjustInsertionPoint passed this value straight through for ScopeKind.Module,
which caused the generated 'open' to be inserted *before* the module
declaration instead of inside it.

Fix: detect when the candidate insertion line is an explicit module
declaration ('module X =') and advance by one so the open lands inside
the module.  This makes the code-fix behaviour consistent with code
completion (issue #789).

Also adds isExplicitModuleDeclaration helper and a regression test.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@Krzysztof-Cieslak Krzysztof-Cieslak marked this pull request as ready for review March 10, 2026 17:48
@Krzysztof-Cieslak Krzysztof-Cieslak merged commit 6bc2e25 into main Mar 10, 2026
19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant