Switch to doc-comments before in OCamlformat (#2016)

* Switch OCamlformat to use --doc-comments=before

* Use a directory exclude list for reformat, exclude Snarky

* Reformat & fix some whitespace errors

* Fix whitespace errors

CONTRIBUTING.md

@@ -11,7 +11,7 @@ Here's the summary if you want to contribute code:
 
 1. Learn some OCaml. The [Real World OCaml](https://dev.realworldocaml.org/toc.html) book is good. Jane Street also has [some exercises](https://github.com/janestreet/learn-ocaml-workshop).
 2. Learn how we use OCaml. We have [a style guide](https://github.com/CodaProtocol/coda/blob/master/docs/style_guide.md) that goes over the important things.
-3. Fork and clone the repo, then set up your development environment. See the [developer README](README-dev.md) for details. 
+3. Fork and clone the repo, then set up your development environment. See the [developer README](README-dev.md) for details.
 4. Find a good first issue. The best issues to start with are those tagged [`category-mentored`](https://github.com/CodaProtocol/coda/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Acategory-mentored). These have a detailed description on how to approach the issue and someone appointed to help people solve it. Once you're famliar with the codebase, [`category-quick-fix`](https://github.com/CodaProtocol/coda/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc++label%3Acategory-quick-fix+) is a good source of reasonably well-defined tasks.
 5. Create a branch in your local clone and implement the solution.
 6. Push the branch to your GitHub fork and create a pull request.
@@ -83,10 +83,10 @@ that we agree to implement.
 This process isn't final, but in general:
 
 1. RFCs will be open for at least a week for discussion.
-2. Once discussion has slowed down or there is consensus, the core eng team 
+2. Once discussion has slowed down or there is consensus, the core eng team
    will initiate a "Final Comment Period". This will include the core eng's
    "merge disposition" (merge/don't merge). The FCP comment should be based
-   on information and arguments already present in the RFC thread. At the 
+   on information and arguments already present in the RFC thread. At the
    end of the FCP, the core eng team decides to do another FCP, leave the FCP
    state for continued discussion, or resolve the RFC by merging/closing
    (whichever the announced disposition was).

DIRECTORY_STRUCTURE.md

@@ -19,14 +19,14 @@ files play.
   - `external/`
     - Local copies of external libraries which we've had to make some tweaks to.
   - `lib/`
-    Libraries powering coda. 
+    Libraries powering coda.
     The libraries here basically fall into two categories.
     1. General purpose data-types and functionality. This includes `snarky`, `fold_lib`, `vrf_lib`, `sgn`, and others.
     2. Application specific functionality, structured as a library. This includes `syncable_ledger`, `staged_ledger`, `transaction_snark`, and others.
   - `app/`
     Applications live here.
     - `cli/`
-      This is the coda client/daemon. It is what you use to run a staker, a snarker, or a simple client 
+      This is the coda client/daemon. It is what you use to run a staker, a snarker, or a simple client
       for sending and receiving transactions.
     - `website/`
       The [Coda Protocol](https://codaprotocol.com) website.

docs/daemon.md

@@ -1,6 +1,6 @@
 # Care and feeding of your Coda daemon
 
-Right now the default config directory is hardcoded to `~/.coda-config`. 
+Right now the default config directory is hardcoded to `~/.coda-config`.
 This will be fixed eventually. In the meantime, you can pass `-config-directory`
 to the daemon to look there.
 

docs/demo.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-Hello! We'll walk you through a short demo to get a local testnet running using Coda. 
+Hello! We'll walk you through a short demo to get a local testnet running using Coda.
 
 Specifically, you'll download a docker image, run it, then play around with the command line interface to create a wallet and send/receive payments.
 
@@ -29,7 +29,7 @@ We'll walk through them one by one.
 
 **Software**: You need to be running **a Debian 9 or Ubuntu 18 distribution**, either natively or in a VM. These are the only operating systems we have tested against. If you don't have this running locally, there are instructions in the [appendix](#appendix) to set up a Google Compute instance.
 
-**Hardware**: We'll be running three nodes on your machine, including a node that is performing intensive zk-SNARK proving work. Therefore, we recommend the following system requirements: 12GB ram (you may be able to get away with less), 4 cores. 
+**Hardware**: We'll be running three nodes on your machine, including a node that is performing intensive zk-SNARK proving work. Therefore, we recommend the following system requirements: 12GB ram (you may be able to get away with less), 4 cores.
 
 ### Download the docker image
 
@@ -87,7 +87,7 @@ $ watch coda client status -daemon-port 8301
 
 #### Create a wallet
 
-A wallet in Coda is just a [public/private key pair](https://en.wikipedia.org/wiki/Public-key_cryptography). The public key corresponds to your publicly available address, and the private key is like a password, required to authorize sending funds from that address. 
+A wallet in Coda is just a [public/private key pair](https://en.wikipedia.org/wiki/Public-key_cryptography). The public key corresponds to your publicly available address, and the private key is like a password, required to authorize sending funds from that address.
 
 First, create a directory for your wallet:
 

docs/lifecycle_of_a_payment_lite.md

@@ -14,7 +14,7 @@ Any member of the network can create and transmit a payment. The payment is
 cryptographically signed with a private key so that the sender’s account can be verified. It is then sent out on the network to be processed.
 
 ## Stage 2 - Proposing a Transition - Bob’s payment gets put in a todo list
-A proposer node is chosen on the network for a given time slot. The currently active proposer choses in-flight payments based on payment fees and places them in a list to be processed called a transition block. Proposers earn currency for building these blocks. The proposer generates a snark defining the structure of the transition block as compared to the previous block (but not yet verifying these new payments). The proposer transmits this new information for snark workers to process. 
+A proposer node is chosen on the network for a given time slot. The currently active proposer choses in-flight payments based on payment fees and places them in a list to be processed called a transition block. Proposers earn currency for building these blocks. The proposer generates a snark defining the structure of the transition block as compared to the previous block (but not yet verifying these new payments). The proposer transmits this new information for snark workers to process.
 
 ## Step 3 - Transaction Snark Proving - Bob’s payment gets snark-signed
 Snark worker nodes on the network begin performing snark calculations on each step of the new transition block. These are individual proofs of each payment and then merge proofs of neighboring payments. Eventually all the payments are verified. Snark workers can earn currency by generating these proofs, paid for by proposers. These proofs are transmitted out over the network.

docs/lifecycle_of_a_payment_technical.md

@@ -186,11 +186,11 @@ A staged ledger can be regarded as a "Pending accounts database" that has transa
 A staged ledger consists of the accounts state (what we currently call ledger) and a data structure called [parallel_scan.ml](../src/lib/parallel_scan/parallel_scan.ml). It keeps track of all the transactions that need to be snarked (grep for `Available_job.t`) to produce a single transaction snark that certifies a set of transactions. This is exposed as Aux in the staged ledger.
 Parallel scan is a tree like structure that stores statements needed to be proved. A statement can be of applying a single transaction `Base` or of composing other statements `Merge`. Snarking of these statements is delegated to snark-workers. The snark workers submit snarks for the corresponding statements which are used by the proposer to update the parallel scan state.
 
-When the propser wins a block, the payments read from the transaction pool are sent to the staged ledger to create a diff `Staged_ledger_diff`. 
-A diff consists of 
+When the propser wins a block, the payments read from the transaction pool are sent to the staged ledger to create a diff `Staged_ledger_diff`.
+A diff consists of
 1. Payments included in the block
 2. A list of proofs that prove some of the transactions (payments, coinbase, and proof-fees) from previous blocks
-3. Coinbase 
+3. Coinbase
 
 There are two primary operations in staged ledger.
 1. Creating a diff :

docs/reporting_guidelines.md

@@ -12,7 +12,7 @@ In your report please include:
 * Names (legal, nicknames, or pseudonyms) of any individuals involved.
   * If there were other witnesses besides you, please try to include them as well.
 * When and where the incident occurred. Please be as specific as possible.
-* Your account of what occurred. 
+* Your account of what occurred.
   * If there is a publicly available record (e.g. a mailing list archive or a public IRC logger) please include a link.
 * Any extra context you believe existed for the incident.
 * If you believe this incident is ongoing.

rfcs/0004-style-guidelines.md

@@ -34,7 +34,7 @@ module Type_equality = struct
     val f : a -> unit
     val g : b -> unit
   end
-  
+
   module Inline (X : X.S) : S with type a = X.a and type b = X.b
   (* return signature becomes:
    * sig
@@ -44,7 +44,7 @@ module Type_equality = struct
    *   val g : b -> unit
    * end
    *)
-   
+
   module Replace (X : X.S) : S with type x := X.a and type b := X.b
   (* return signature becomes:
    * sig
@@ -59,7 +59,7 @@ module Module_equality = struct
     module X : X.S
     val f : X.t -> unit
   end
-  
+
   module Inline (X : X.S) : S with module X = X
   (* return signature becomes:
    * sig
@@ -68,7 +68,7 @@ module Module_equality = struct
    *   val g : X.b -> unit
    * end
    *)
-  
+
   module Replace (X : X.S) : S with module X := X
   (* return signature becomes:
    * sig

rfcs/0006-delegation-of-stake.md

@@ -102,7 +102,7 @@ The main thing this design has going for it is you only need to do one VRF evalu
   - `delegated_to_me : Currency.Amount.t`
   - `delegated_by_me : Currency.Amount.t`
 
-  The invariants we maintain are 
+  The invariants we maintain are
   - For any account corresponding to public key `p`, `delegated_stake` is the sum
     `\sum_{a : Account.t, a.delegated_by_me = p} a.delegated_to_me`.
   - For any account `a`, `a.delegated_by_me <= a.balance`.

rfcs/0014-address-encoding.md

@@ -9,7 +9,7 @@ Change address encoding from Base64 to Base58.
 
 First, it's a standard format across other well known cryptocurrencies (Bitcoin, Zcash, Monero). That means most entities in the ecosystem, from end-users to exchanges, will be more familiar and comfortable with Base58 encodings than what we have currently.
 
-Additionally, quoting from the [Bitcoin Wiki](https://en.bitcoin.it/wiki/Base58Check_encoding#Background): 
+Additionally, quoting from the [Bitcoin Wiki](https://en.bitcoin.it/wiki/Base58Check_encoding#Background):
 
 ```
 // Why base-58 instead of standard base-64 encoding?
@@ -40,7 +40,7 @@ We should also add a unique prefix to prevent Coda from being accidentally sent
 ## Rationale and alternatives
 [rationale-and-alternatives]: #rationale-and-alternatives
 
-We could continue to use Base64, change to hex, or use a custom encoding. 
+We could continue to use Base64, change to hex, or use a custom encoding.
 
 I'd recommend Base58 because it is the standard, is more compact than hex (which matters given our key size), and it has the benefits enumerated above. I don't see many benefits with developing a custom encoding.
 

rfcs/0015-module-versioning.md

@@ -22,7 +22,7 @@ annotation on types.
 ### Explicit versioning
 
 The `bin_io` representation and associated `bin_prot` library are
-claimed to be type-safe when used in OCaml (see 
+claimed to be type-safe when used in OCaml (see
 [Jane Street bin\_prot](https://github.com/janestreet/bin_prot/).
 Moreover, other programming languages don't appear to be able to
 produce or consume this representation. Therefore, type and versioning
@@ -63,7 +63,7 @@ module Some_data = struct
       type latest = t
 
       let to_latest t = t
-	  
+
 	  include Make_version (T)
     end
 
@@ -140,7 +140,7 @@ module Some_data = struct
       type latest = Latest.t (* changed, was t *)
 
       let to_latest = ...    (* changed, was the identity *)
-	  
+
 	  include Make_version (T)
     end
 
@@ -248,7 +248,7 @@ The file `docs/style-guide.md` mentions versioning of stable module
 types.
 
 PR #1645, already merged, partially implements a module registration
-mechanism.  That implementation deals only with the `bin_io` 
+mechanism.  That implementation deals only with the `bin_io`
 representation, not `yojson` or `sexp`.
 
 PR #1653, already merged, more completely implements a module

src/app/kademlia-haskell/packages.nix

@@ -441,7 +441,7 @@ let
            homepage = "http://github.com/ryantm/hdbc-mysql";
            description = "MySQL driver for HDBC";
            license = "LGPL";
-         }) {inherit (pkgs) mysqlclient; inherit (pkgs) openssl; 
+         }) {inherit (pkgs) mysqlclient; inherit (pkgs) openssl;
 inherit (pkgs) zlib;};
       "HDBC-session" = callPackage
         ({ mkDerivation, base, HDBC, stdenv }:
@@ -1361,7 +1361,7 @@ inherit (pkgs) zlib;};
            homepage = "https://github.com/xmonad/X11";
            description = "A binding to the X11 graphics library";
            license = stdenv.lib.licenses.bsd3;
-         }) {inherit (pkgs.xorg) libXScrnSaver; inherit (pkgs.xorg) libXext; 
+         }) {inherit (pkgs.xorg) libXScrnSaver; inherit (pkgs.xorg) libXext;
 inherit (pkgs.xorg) libXinerama; inherit (pkgs.xorg) libXrender;};
       "X11-xft" = callPackage
         ({ mkDerivation, base, libXft, stdenv, utf8-string, X11 }:
@@ -5022,7 +5022,7 @@ inherit (pkgs.xorg) libXinerama; inherit (pkgs.xorg) libXrender;};
            doCheck = false;
            description = "Low-level bindings to GLFW OpenGL library";
            license = stdenv.lib.licenses.bsd3;
-         }) {inherit (pkgs) libGL; inherit (pkgs.xorg) libXext; 
+         }) {inherit (pkgs) libGL; inherit (pkgs.xorg) libXext;
 inherit (pkgs.xorg) libXfixes;};
       "bindings-libzip" = callPackage
         ({ mkDerivation, base, bindings-DSL, libzip, stdenv }:
@@ -12678,7 +12678,7 @@ inherit (pkgs.xorg) libXfixes;};
            homepage = "https://github.com/chrisdone/freenect";
            description = "Interface to the Kinect device";
            license = stdenv.lib.licenses.bsd3;
-         }) {inherit (pkgs) freenect; inherit (pkgs) freenect_sync; 
+         }) {inherit (pkgs) freenect; inherit (pkgs) freenect_sync;
 inherit (pkgs) libfreenect;};
       "freer-simple" = callPackage
         ({ mkDerivation, base, natural-transformation, stdenv
@@ -12982,8 +12982,8 @@ inherit (pkgs) libfreenect;};
            doCheck = false;
            description = "A Haskell binding to a subset of the GD graphics library";
            license = stdenv.lib.licenses.bsd3;
-         }) {inherit (pkgs) expat; inherit (pkgs) fontconfig; 
-inherit (pkgs) freetype; inherit (pkgs) gd; 
+         }) {inherit (pkgs) expat; inherit (pkgs) fontconfig;
+inherit (pkgs) freetype; inherit (pkgs) gd;
 inherit (pkgs) libjpeg; inherit (pkgs) libpng; inherit (pkgs) zlib;};
       "gdp" = callPackage
         ({ mkDerivation, base, lawful, stdenv }:

src/app/lite/main.ml

@@ -852,7 +852,7 @@ let state_html state =
   else div [Style.(render (of_class "animate-opacity o-100"))] contents
 
 (* HACK: To get a web worker running for the verifier from s3 and avoid remote origin issues,
-  we have to download the code via a get request, encapsulate it in a Blob object to get 
+  we have to download the code via a get request, encapsulate it in a Blob object to get
   an url link and then feed the url link into verifier*)
 let run_verifier ~f =
   let verifier_url = sprintf !"%s/verifier_main.bc.js" Web_response.s3_link in

src/app/reformat/reformat.ml

@@ -4,6 +4,16 @@ open Async
 (* If OCamlformat ever breaks on any files add their paths here *)
 let whitelist = []
 
+let dirs_whitelist =
+  [ ".git"
+  ; "_build"
+  ; "stationary"
+  ; ".un~"
+  ; "external"
+  ; "ocamlformat"
+  ; "node_modules"
+  ; "snarky" ]
+
 let rec fold_over_files ~path ~process_path ~init ~f =
   let%bind all = Sys.ls_dir path in
   Deferred.List.fold all ~init ~f:(fun acc x ->
@@ -20,13 +30,9 @@ let main dry_run check path =
       ~process_path:(fun kind path ->
         match kind with
         | `Dir ->
-            (not (String.is_suffix ~suffix:".git" path))
-            && (not (String.is_suffix ~suffix:"_build" path))
-            && (not (String.is_suffix ~suffix:"stationary" path))
-            && (not (String.is_suffix ~suffix:".un~" path))
-            && (not (String.is_suffix ~suffix:"external" path))
-            && (not (String.is_suffix ~suffix:"ocamlformat" path))
-            && not (String.is_suffix ~suffix:"node_modules" path)
+            not
+              (List.exists dirs_whitelist ~f:(fun s ->
+                   String.is_suffix ~suffix:s path ))
         | `File ->
             (not
                (List.exists whitelist ~f:(fun s ->
@@ -39,15 +45,17 @@ let main dry_run check path =
           return ()
         in
         if check then
-          let prog, args = ("ocamlformat", [file]) in
+          let prog, args = ("ocamlformat", ["--doc-comments=before"; file]) in
           let%bind formatted = Process.run_exn ~prog ~args () in
           let%bind raw = Reader.file_contents file in
           if formatted <> raw then (
             eprintf "File: %s has needs to be ocamlformat-ed\n" file ;
             exit 1 )
           else return ()
         else
-          let prog, args = ("ocamlformat", ["-i"; file]) in
+          let prog, args =
+            ("ocamlformat", ["--doc-comments=before"; "-i"; file])
+          in
           if dry_run then dump prog args
           else
             let%map _stdout = Process.run_exn ~prog ~args () in

src/app/trace-tool/src/main.rs

@@ -35,7 +35,7 @@ use EventKind::*;
 
 named!(parse_trace_event<&[u8], TraceEvent>,
        switch!(le_u8,
-       0 => do_parse!(ns: le_u64 >> tid: le_u64 >> 
+       0 => do_parse!(ns: le_u64 >> tid: le_u64 >>
                           s: length_data!(le_u64) >>
                           (TraceEvent {
                               ns_since_epoch: ns as f64,

src/app/website/Makefile

@@ -1,3 +1,3 @@
 .PHONY: all
 all:
-	dune exec website -- public -working-directory "$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))" 
+	dune exec website -- public -working-directory "$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))"