-
Notifications
You must be signed in to change notification settings - Fork 804
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
Conversation
@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. |
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. |
7a75d8b
to
44caca0
Compare
Hello @dsyme, fsprojects/fantomas#1953 and fsprojects/fantomas#1954 have been fixed. Out of interest, did you format the formatted files to check if they are idempotent? |
Thanks! We have to ask a team at microsoft to put new packages up, about 24h turnaround, I've done that now |
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 :) |
@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 |
@nojaf there is one other non-idempotency, reported here: fsprojects/fantomas#1974 |
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. |
This is ready. Now that dev17.0 has been integrated into main it' a goiod time to do this. |
There was a problem hiding this 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?
-> printerResidueTy: TType | ||
-> printerResultTy: TType | ||
-> TType list * TType * TType * TType[] * (range * int) list * string | ||
m: range -> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
Oh wow, thank you for this! That's so useful. I guess we should be using this for all cleanup PRs too |
I have updated this to fantomas-tool 4.7.5 but am getting an error:
|
@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
|
@vzarytovskii @KevinRansom Can you approve if you agree please? Thanks |
There was a problem hiding this 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?
Sounds good to me (though beware sometimes the data expressions in tests are massively expanded by fantomas formatting) I'll update this |
@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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting
There was a problem hiding this comment.
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*) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 [] |
There was a problem hiding this comment.
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 🙂)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's wrong here? Did you catch up on https://docs.microsoft.com/en-us/dotnet/fsharp/style-guide/formatting#formatting-types-in-signatures?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
* 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
Some low hanging fruit in applying standard source code formatting is to format all our signature files.
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 useint array
instead anyway, the community have requested that be considered normal)However we can still merge this
Some files fail formatting, see src\fsharp.fantomasignore. I raised two issues about those so far
val mutable
in signature loses 'mutable' fsprojects/fantomas#1954