[Repo Assist] Fix open insertion position for nested explicit modules (issue #789)#1495
Merged
Krzysztof-Cieslak merged 2 commits intomainfrom Mar 10, 2026
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 This is an automated PR from Repo Assist.
Summary
Fixes the inconsistency reported in #789 where the code-fix path inserted an
opendeclaration before a nested module declaration, while code-completion correctly placed it inside the module.Root cause
FSharp.Compiler.Service'sParsedInput.TryFindInsertionContextsetsInsertionContext.Pos.Lineto the module declaration line itself (e.g. the line containingmodule Foo =) rather than the first line inside the module.adjustInsertionPointpassed this value unchanged forScopeKind.Module, soopenFixcomputeddocLine = l - 1and inserted theopenstatement immediately before themodule Foo =line.ParsedInput.FindNearestPointToInsertOpenDeclaration(used by code-completion) does not have this quirk, which explains the pre-existing inconsistency.Fix
Added a helper
isExplicitModuleDeclarationthat recognisesmodule X =lines (with a trailing=, to distinguish them from top-level implicit module headers). In the| _ ->branch ofadjustInsertionPoint, when the candidate insertion line is such a declaration, the insertion point is advanced by one so theopenlands on the first line inside the module.Before (code-fix for cursor inside
module Nested =):After:
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 onmainbefore 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.