Enable scalafmt on this project

[He-Pin]

As the scala-native will learn more from this project, and the scala-native current has scalafmt 2.4.2 enabled, let this project formatted with scalafmt will help for code sharing.
refs:#2701
refs:scala-native/scala-native#1787

[sjrd]

This was tried before, but scalafmt wasn't up to the standard of formatting in this codebase.

Does scalafmt support binpacking well, these days?

[sjrd]

If someone comes up with a PR for enabling scalafmt even in just one meaningful project (such as library or linker) and that doesn't cause more 1 non-fix formatting change per 1000 loc, we can consider it.

[He-Pin]

I think this should be better to hold a llittle longer
refs: https://github.com/scalameta/scalafmt/issues?q=is%3Aissue+is%3Aopen+label%3Abug

[gzm0]

What do you mean by a "non-fix formatting change"?

[sjrd]

A fix formatting change would be a change where scalafmt actually fixes the formatting according to your existing standards. So that would be somewhere where we had already let badly-formatted code into the codebase. I'm happy for scalafmt to correct those if it finds them.

A non-fix formatting change would be a change where scalafmt reformatted something that was already correct by our standards.

[gzm0]

OK, got it. That means (minor) changes to our coding standards for the sake of being able to use scalafmt are out of scope entirely?

[sjrd]

I don't want to make any blanket statement, so I wouldn't say "out of scope entirely", but "most likely out of scope". The issue with changes in coding standard, applied by a tool, is that even when minor, they tend to affect a very large portion of lines of code. And that is so many lines of code for which blame will be deteriorated.

Also the trouble with such tools is that they evolve themselves, and change things. So when you upgrade, your coding style changes and you have another wave of changes everywhere, further deteriorating your blame experience.

[gzm0]

/cc @MaximeKjaer

[gzm0]

Related: https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame

[sjrd]

That looks extremely useful!

[MaximeKjaer]

I am indeed planning to open a PR based on the argument in that link quite soon 😉