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

Apply standard source code formatting to src/fsharp/*.fsi #12346

Merged
merged 18 commits into from
May 4, 2022
Merged

Conversation

dsyme
Copy link
Contributor

@dsyme dsyme commented Nov 5, 2021

Some low hanging fruit in applying standard source code formatting is to format all our signature files.

git checkout ft6
git fetch home
git reset --hard home/main
git merge 5c091ba8f
dotnet tool restore
dotnet fantomas src\fsharp
git commit -a -m "apply formatting"
git push -f origin ft6

There's two bits of formatting I don't like

  • int [] for arrays (not the extra space, which fantomas adds, though we should likely switch to use int array instead anyway, the community have requested that be considered normal)
  • Overly verbose formatting of some attributes

However we can still merge this

Some files fail formatting, see src\fsharp.fantomasignore. I raised two issues about those so far

@dsyme
Copy link
Contributor Author

dsyme commented Nov 5, 2021

@KevinRansom @TIHan @brettfo @vzarytovskii This is ready.

We won't run formatting checks as standard for checkin but will add it soon. And note this is only the signature files so far. The implementation files will be much more challenging

Some reformatting will occur with future versions of Fantomas as we continue to improve the defaults.

@dsyme dsyme disabled auto-merge November 6, 2021 00:02
@dsyme dsyme marked this pull request as draft November 6, 2021 00:02
@dsyme
Copy link
Contributor Author

dsyme commented Nov 6, 2021

Converting to draft as this may conflict badly with merges between main and dev17.0.

We may also have conflicts with outstanding PRs such as for nullable reference types and #12265 and #11681 and #6805. In theory should be possible to simply re-run formatting on those PRs before merging together. But we have to be careful not to create unnecessary pain for ourselves by doing this at the wrong time.

Anyway I think we should wait at least until dev17.0 is merged in. It's really easy to run the formatting again so it's no problem to wait.

@dsyme dsyme marked this pull request as ready for review November 20, 2021 01:48
@nojaf
Copy link
Contributor

nojaf commented Nov 20, 2021

Hello @dsyme, fsprojects/fantomas#1953 and fsprojects/fantomas#1954 have been fixed.
They are part of the 4.6.0-alpha-008 release.
I'm not sure if you can just update if newer versions are present on NuGet.
So, perhaps you want to update in another PR.

Out of interest, did you format the formatted files to check if they are idempotent?

@dsyme
Copy link
Contributor Author

dsyme commented Nov 20, 2021

I'm not sure if you can just update if newer versions are present on NuGet.

Thanks! We have to ask a team at microsoft to put new packages up, about 24h turnaround, I've done that now

@dsyme
Copy link
Contributor Author

dsyme commented Nov 20, 2021

fsprojects/fantomas#1953 and fsprojects/fantomas#1954 have been fixed.

This is great! I was actually going to work on those :) Thank you, I'll try to make it up to you by fixing other things :)

@dsyme
Copy link
Contributor Author

dsyme commented Nov 20, 2021

@nojaf There was one case of non-idempotency, but it's poor input code so I don't mind changing it. Do you want me to report it?

    type ProviderGeneratedType = ProviderGeneratedType of (*ilOrigTyRef*)ILTypeRef * (*ilRenamedTyRef*)ILTypeRef * ProviderGeneratedType list

goes to

    type ProviderGeneratedType =
        | ProviderGeneratedType of ILTypeRef (*ilRenamedTyRef*)  * ILTypeRef * ProviderGeneratedType list (*ilOrigTyRef*)

then to

    type ProviderGeneratedType =
        | ProviderGeneratedType of
            ILTypeRef (*ilRenamedTyRef*)  *
            ILTypeRef *
            ProviderGeneratedType list (*ilOrigTyRef*)

I'm just going to change the original code to

    type ProviderGeneratedType = ProviderGeneratedType of ilOrigTyRef: ILTypeRef * ilRenamedTyRef: ILTypeRef * ProviderGeneratedType list

@dsyme
Copy link
Contributor Author

dsyme commented Nov 20, 2021

@nojaf there is one other non-idempotency, reported here: fsprojects/fantomas#1974

@nojaf
Copy link
Contributor

nojaf commented Nov 20, 2021

Do you want me to report it?

Yes, it is an interesting case where we at first glance, don't print trivia. Please report it and mention it is a low priority.
Thanks!

@dsyme
Copy link
Contributor Author

dsyme commented Nov 20, 2021

This is ready. Now that dev17.0 has been integrated into main it' a goiod time to do this.

Copy link
Member

@KevinRansom KevinRansom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsyme Why do we have tuple arguments with the * at the start of the line rather than the end?

src/fsharp/CheckDeclarations.fsi Outdated Show resolved Hide resolved
-> printerResidueTy: TType
-> printerResultTy: TType
-> TType list * TType * TType * TType[] * (range * int) list * string
m: range ->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interestingly, here the format is how I like it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, we have the -> at the end OK. Full context is linked in https://github.com/fsprojects/fantomas/issues/1955. THe problem is in mixed curried/tupled signatures but we rarely use those

@dsyme
Copy link
Contributor Author

dsyme commented Nov 25, 2021

@dsyme you might also want to add a ignore revs file once this is ready. See https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame

Oh wow, thank you for this! That's so useful. I guess we should be using this for all cleanup PRs too

@dsyme
Copy link
Contributor Author

dsyme commented Apr 20, 2022

I have updated this to fantomas-tool 4.7.5 but am getting an error:

Processing .\range.fsi
The following exception occurs while formatting stdin: System.Exception: Fantomas is trying to format the input multiple times due to the detect of multiple defines.
There is a problem with merging all the code back together.
[CHECK_LINE0_TYPES] has 4 fragments
[] has 2 fragments

@dsyme
Copy link
Contributor Author

dsyme commented Apr 20, 2022

@vzarytovskii @KevinRansom I've updated things to include a "CheckCodeFormatting" CI job to see if code formatting is up-to-date in the formatted files (which are primarily just signature files)

Once green I think we can soon go ahead with merging this as first steps? Then iteratively

  1. start to apply code formatting to more files
  2. improve our signature files to include more metadata, better comments, less use of mixed tuple/curried signatures.
  3. improve fantomas

@dsyme
Copy link
Contributor Author

dsyme commented Apr 28, 2022

@vzarytovskii @KevinRansom Can you approve if you agree please? Thanks

Copy link
Member

@vzarytovskii vzarytovskii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, perhaps we can do some tests next.
@KevinRansom does it look okay to you?

@dsyme
Copy link
Contributor Author

dsyme commented Apr 30, 2022

Looks good to me, perhaps we can do some tests next.

Sounds good to me (though beware sometimes the data expressions in tests are massively expanded by fantomas formatting)

I'll update this

@dsyme
Copy link
Contributor Author

dsyme commented May 4, 2022

@vzarytovskii @KevinRansom @nojaf OK, Fantomas is now being used to format the signature files in this repository

env:
DOTNET_ROLL_FORWARD_TO_PRERELEASE: 1
displayName: Install tools
- script: dotnet fantomas src\fsharp --check
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsyme sorry, I didn't catch this, but I don't think the \ will work on a Linux VM.
I don't believe the check will execute properly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did have then check fail, my understanding is it now succeeds. Odd

exception AssemblyNotResolved of (*originalName*) string * range
exception AssemblyNotResolved of string * range (*originalName*)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nojaf Have you seen changes related to comments like this and ones below?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, I didn't really review the changes in this PR.

-> byte[]

seq<int32 * int32> ->
byte []
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like another place worth fixing (if not yet 🙂)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was about the added space.

Copy link
Contributor

@nojaf nojaf May 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The space between the byte and [] has been resolved. Available in the v5 alphas.
The space before byte is part of the indentation of the return type.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, thanks for confirming!

* candidates: OverloadInformation list // methodNames may be different (with operators?), this is refactored from original logic to assemble overload failure message
* cx: TraitConstraintInfo option
| NoOverloadsFound of methodName: string * candidates: OverloadInformation list * cx: TraitConstraintInfo option
| PossibleCandidates of
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another place where an empty line between multiline declarations would look great (as discussed in fsprojects/fantomas#2198).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be pitched in the style guide.

charlesroddie pushed a commit to charlesroddie/fsharp that referenced this pull request May 2, 2023
* add fantomasignore

* add fantomasignore

* fix ignores

* fix ignores

* update fantomasignore

* prefix before formatting

* prefix before formatting

* bump fantomas version

* update tool

* update tool

* update tool

* update tool

* add job

* add job

* apply formatting
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants