Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

visualstudio open namespace codefix has wrong indentation in some cases #10521

Open
Tracked by #15408
smoothdeveloper opened this issue Nov 22, 2020 · 5 comments · Fixed by #15912
Open
Tracked by #15408

visualstudio open namespace codefix has wrong indentation in some cases #10521

smoothdeveloper opened this issue Nov 22, 2020 · 5 comments · Fixed by #15912
Labels
Area-FCS Area-LangService-CodeFixes Code fixes associated with diagnostics Bug Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code.
Milestone

Comments

@smoothdeveloper
Copy link
Contributor

In indented context, the open namespace code fix puts the declaration at wrong indentation level.

It doesn't always affect the code, but when there are type extensions, it breaks it.

module Foo =
  open System

  type DateTime with
    member x.X() = ()

  let a () =
    let t = Task.Factory.StartNew(fun () -> 1) // use the code fix on Task
    ()

open namespace indentiation glitch

Related information

VS2019 16.8

@smoothdeveloper
Copy link
Contributor Author

Another case:

[<AutoOpen>] // will insert after the attribute
module Foo2 =
  // would prefer here if "Always place open statements at the top level" is unchecked
  let a () =
    let t = Task.Factory.StartNew(fun () -> 1) // use the code fix on Task
    ()

Currently
Here it introduces open ... on a new line just after the attribute making the code invalid.

Given the settings, I'd prefer open ... to land on a new line just above let a () =

image

@smoothdeveloper
Copy link
Contributor Author

@vzarytovskii/@cartermp do you know if there are tests for this code fix, is it easy to add one for each cases?

@cartermp cartermp added this to the Backlog milestone Nov 24, 2020
@cartermp
Copy link
Contributor

This seems like a bug in the tryfindinsertioncontext routine here:

let tryFindInsertionContext (currentLine: int) (ast: ParsedInput) (partiallyQualifiedName: MaybeUnresolvedIdents) (insertionPoint: OpenStatementInsertionPoint) =

It's complicated code unfortunately. I'm not sure if it's under test. We have decent testing for the analysis part, but not the insertion part.

@KevinRansom KevinRansom added the Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code. label Jul 21, 2021
@vzarytovskii vzarytovskii moved this to Not Planned in F# Compiler and Tooling Jun 17, 2022
@psfinaki
Copy link
Member

Okay this still reproduces the "Always place open statements at the top level" off.

@psfinaki psfinaki added the Area-LangService-CodeFixes Code fixes associated with diagnostics label Jun 15, 2023
@psfinaki psfinaki mentioned this issue Jun 15, 2023
85 tasks
@github-project-automation github-project-automation bot moved this from Not Planned to Done in F# Compiler and Tooling Sep 5, 2023
@psfinaki psfinaki reopened this Sep 5, 2023
@github-project-automation github-project-automation bot moved this from Done to In Progress in F# Compiler and Tooling Sep 5, 2023
@psfinaki
Copy link
Member

psfinaki commented Sep 5, 2023

Fixed partially as of now - the code fix doesn't break the code anymore but the location of the inserted code is still not precise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-FCS Area-LangService-CodeFixes Code fixes associated with diagnostics Bug Impact-Low (Internal MS Team use only) Describes an issue with limited impact on existing code.
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

4 participants