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

Named string argument to type provider requires a space prior to '@', which Fantomas removes #1209

Closed
2 of 3 tasks
reinux opened this issue Oct 30, 2020 · 1 comment · Fixed by #1298
Closed
2 of 3 tasks
Labels
bug (soundness) good first issue Long hanging fruit: easy issue to get your feet wet!

Comments

@reinux
Copy link

reinux commented Oct 30, 2020

Issue created from fantomas-online

Code

type Graphml = XmlProvider<Schema= @"http://graphml.graphdrawing.org/xmlns/1.0/graphml-structure.xsd">

Error

Fantomas was able to format the code but the result appears to be invalid F# code.
Please open an issue.

Formatted result:

type Graphml = XmlProvider<Schema=@"http://graphml.graphdrawing.org/xmlns/1.0/graphml-structure.xsd">

Problem description

F# requires the '@' to have a space before it in type provider arguments. This makes sense, as <@ is used for code quotations.

Weirdly, the compiler also requires a space even if the preceding token isn't a '<', e.g. if it's a = or a ,.

I think Fantomas is behaving correctly, but unless the fsc parser can be fixed by 5.0's release, it may be preferable to work around it.

If you agree that this should be addressed by Fantomas, I'd like to try tackling this bug (along with the other disappearing comments one), but I don't know if I'll have time to study Fantomas' workings for at least a couple more weeks :(

I've submitted an issue on dotnet/fsharp as well.

Extra information

  • The formatted result breaks by code.
  • The formatted result gives compiler warnings.
  • I or my company would be willing to help fix this.

Options

Fantomas Master at 10/26/2020 19:07:04 - be9212d

Default Fantomas configuration

@nojaf
Copy link
Contributor

nojaf commented Oct 30, 2020

I think we can extract firstItemHasAtSignBeforeString and re-use it to solve this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug (soundness) good first issue Long hanging fruit: easy issue to get your feet wet!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants