Merge master and fix conflicts

Author: erewok

.travis.yml

@@ -35,7 +35,34 @@ Some things we like:
 Though we aren't sticklers for style, the `.stylish-haskell.yaml` and `HLint.hs`
 files in the repository provide a good baseline for consistency.
 
-**Important**: please do not modify the changelog files nor the versions of the servant packages you are sending patches for. We take care of this before every release and do it uniformly for all the servant packages, so there's no need to worry about this for your pull requests.
+**Important**: please do not modify the versions of the servant packages you are sending patches for.
+
+## Changelog entries
+
+We experiment with using [changelog-d tool](https://github.com/phadej/changelog-d) to assemble changelogs.
+You are not required to install it.
+
+In each PR please add a file to `changelog.d` directory named after issue you are solving or the pull request itself (in a separate commit after you know the pull request number). For example
+
+```cabal
+synopsis: One sentence summary of the change.
+prs: #1219
+issues: #1028
+
+description: {
+
+A longer description. Small changes don't need this.
+Bigger ones definitely do, for example we try to include migration hints
+for breaking changes.
+
+However if you don't know what to write, that's ok too.
+
+By the way, the braces around are omitted when the file is parsed.
+They can be used so the field doesn't need to be indented, which is handy
+for prose.
+
+}
+```
 
 ## PR process
 

CONTRIBUTING.md

@@ -20,3 +20,13 @@ build-ghcjs :
 
 packdeps :
 	packdeps */*.cabal
+
+doctest : doctest-servant doctest-servant-server
+	perl -i -e 'while (<ARGV>) { print unless /package-id\s+base-compat-\d+(\.\d+)*/; }' .ghc.environment.*
+
+doctest-servant :
+	(cd servant && doctest src)
+	(cd servant && doctest test/Servant/LinksSpec.hs)
+
+doctest-servant-server :
+	(cd servant-server && doctest src)

Makefile

@@ -1,8 +1,12 @@
+distribution: bionic
 folds: all-but-test
 branches: master
 jobs-selection: any
 google-chrome: True
 ghcjs-tests: True
+doctest: True
+doctest-filter-packages: base-compat-batteries
+doctest-skip:            tutorial
 
 -- https://github.com/haskell/cabal/issues/6176
 ghcjs-tools: hspec-discover

cabal.haskell-ci

@@ -15,8 +15,8 @@ packages:
   servant-pipes/
 
 -- servant GHCJS
-packages:
-  servant-jsaddle/
+-- packages:
+--   servant-jsaddle/
 
 -- Cookbooks
 packages:
@@ -38,8 +38,6 @@ packages:
   doc/cookbook/using-free-client
   -- doc/cookbook/open-id-connect
 
-
-
 tests: True
 optimization: False
 -- reorder-goals: True
@@ -62,3 +60,8 @@ allow-newer: openssl-streams-1.2.2.0:network
 -- MonadFail
 -- https://github.com/nurpax/sqlite-simple/issues/74
 constraints: sqlite-simple < 0
+
+constraints: base-compat ^>=0.11
+
+-- needed for doctests
+write-ghc-environment-files: always

cabal.project

@@ -0,0 +1,2 @@
+organization: haskell-servant
+repository:   servant

changelog.d/config

@@ -0,0 +1,18 @@
+synopsis: Add NoContentVerb
+prs: #1228 #1219
+issues: #1028
+significance: significant
+
+description: {
+
+The `NoContent` API endpoints should now use `NoContentVerb` combinator.
+The API type changes are usually of the kind 
+
+```diff
+- :<|> PostNoContent '[JSON] NoContent
++ :<|> PostNoContent 
+```
+
+i.e. one doesn't need to specify the content-type anymore. There is no content.
+
+}

changelog.d/issue1028

@@ -0,0 +1,12 @@
+synopsis: Fix Verb with headers checking content type differently
+packages: servant-client-core servant-client
+prs: #1204
+issues: #1200
+packages: servant-client servant-client-core servant-http-streams
+
+description: {
+
+For `Verb`s with response `Headers`, the implementation didn't check
+for the content-type of the response. Now it does.
+
+}

changelog.d/issue1200

@@ -0,0 +1,16 @@
+synopsis: Merge documentation from duplicate routes
+packages: servant-docs
+prs: #1241
+issues: #1240
+
+description: {
+
+Servant supports defining the same route multiple times with different
+content-types and result-types, but servant-docs was only documenting
+the first of copy of such duplicated routes. It now combines the
+documentation from all the copies.
+
+Unfortunately, it is not yet possible for the documentation to specify
+multiple status codes.
+
+}

changelog.d/issue1240

@@ -0,0 +1,3 @@
+synopsis: Progress on servant-jsaddle
+packages: servant-jsaddle
+prs: #1216

changelog.d/jsaddle

@@ -0,0 +1,17 @@
+synopsis: `Capture` can be `Lenient`
+issues: #1155
+prs: #1156
+significance: significant
+description: {
+
+You can specify a lenient capture as
+
+```haskell
+:<|> "capture-lenient"  :> Capture' '[Lenient] "foo" Int :> GET
+```
+
+which will make the capture always succeed. Handlers will be of the
+type `Either String CapturedType`, where `Left err` represents
+the possible parse failure.
+
+}

changelog.d/pr1156

@@ -0,0 +1,7 @@
+synopsis: Add sponsorship button
+prs: #1190
+description: {
+
+[Well-Typed](https://www.well-typed.com/)
+
+}

changelog.d/pr1190

@@ -0,0 +1,3 @@
+synopsis: Prevent race-conditions in testing
+packages: servant-docs
+prs: #1194

changelog.d/pr1194

@@ -0,0 +1,4 @@
+synopsis: `HasClient` instance for `Stream` with `Headers`
+packages: servant-client servant-client servant-http-streams
+prs: #1197
+issues: #1170

changelog.d/pr1197

@@ -0,0 +1,3 @@
+synopsis: Remove unused extensions from cabal file
+packages: servant
+prs: #1201

changelog.d/pr1201

@@ -0,0 +1,12 @@
+synopsis: Added a function to create Client.Request in ClientEnv
+packages: servant-client
+significance: significant
+prs: #1213 #1255
+description: {
+
+The new member `makeClientRequest` of `ClientEnv` is used to create
+`http-client` `Request` from `servant-client-core` `Request`.
+This functionality can be used for example to set
+dynamic timeouts for each request.
+
+}

changelog.d/pr1213

@@ -0,0 +1,3 @@
+synopsis: Redact the authorization header in Show and exceptions
+packages: servant-client
+prs: #1238

changelog.d/pr1238

@@ -0,0 +1,15 @@
+synopsis: use queryString to parse QueryParam, QueryParams and QueryFlag
+packages: servant-server
+prs: #1249 #1262
+significance: significant
+description: {
+
+Some APIs need query parameters rewriting, e.g. in order to support
+ for multiple casing (camel, snake, etc) or something to that effect.
+
+This could be easily achieved by using WAI Middleware and modyfing
+request's `Query`. But QueryParam, QueryParams and QueryFlag use
+`rawQueryString`. By using `queryString` rather then `rawQueryString`
+we can enable such rewritings.
+
+}

changelog.d/pr1249

@@ -0,0 +1,11 @@
+synopsis: Make packages `build-type: Simple`
+packages: servant servant-server
+prs: #1263
+significance: significant
+description: {
+
+We used `build-type: Custom`, but it's problematic e.g.
+for cross-compiling. The benefit is small, as the doctests
+can be run other ways too (though not so conviniently).
+
+}

changelog.d/pr1263

@@ -0,0 +1,8 @@
+synopsis: Try changelog-d for changelog management
+prs: #1230
+
+description: {
+
+Check the [CONTRIBUTING.md](https://github.com/haskell-servant/servant/blob/master/CONTRIBUTING.md) for details
+
+}

changelog.d/z-changelog-d

@@ -0,0 +1,19 @@
+synopsis: CI and testing tweaks.
+prs:
+  #1154
+  #1157
+  #1182
+  #1214
+  #1229
+  #1233
+  #1242
+  #1247
+  #1250
+  #1258
+
+description: {
+
+We are experiencing some bitrotting of cookbook recipe dependencies,
+therefore some of them aren't build as part of our CI anymore.
+
+}

changelog.d/z-ci-tweaks

@@ -0,0 +1,9 @@
+synopsis: New cookbook recipes
+prs: #1171 #1088 #1198
+
+description: {
+
+- [OIDC Recipe](#TODO)
+- [MySQL Recipe](#TODO)
+
+}

changelog.d/z-cookbook

@@ -0,0 +1,9 @@
+synopsis: Dependency upgrades
+prs:
+  #1173
+  #1181
+  #1183
+  #1188
+  #1224
+  #1245
+  #1257

changelog.d/z-dependency-upgrades

@@ -0,0 +1,8 @@
+synopsis: Documentation updates
+prs:
+  #1162
+  #1174
+  #1175
+  #1234
+  #1244
+  #1247

changelog.d/z-documentation-updates

@@ -2,7 +2,7 @@
 
 or simply put: _a practical introduction to `Servant.Client.Free`_.
 
-Someone asked on IRC how one could access the intermediate Requests (resp. Responses) 
+Someone asked on IRC how one could access the intermediate Requests (resp. Responses)
 produced (resp. received) by client functions derived using servant-client.
 My response to such inquiries is: to extend `servant-client` in an ad-hoc way (e.g for testing or debugging
 purposes), use `Servant.Client.Free`. This recipe shows how.
@@ -119,7 +119,7 @@ Now we can use `servant-client`'s internals to convert servant's `Request`
 to http-client's `Request`, and we can inspect it:
 
 ```haskell
-        let req' = I.requestToClientRequest burl req
+        let req' = I.defaultMakeClientRequest burl req
         putStrLn $ "Making request: " ++ show req'
 ```
 
@@ -136,11 +136,11 @@ and calling the continuation. We should get a `Pure` value.
 
 ```haskell
         let res = I.clientResponseToResponse id res'
-        
+
         case k res of
             Pure n ->
                 putStrLn $ "Expected 1764, got " ++ show n
-            _ -> 
+            _ ->
                 putStrLn "ERROR: didn't got a response"
 ```
 
@@ -153,7 +153,7 @@ and responses available for us to inspect, since `RunClient` only gives us
 access to one `Request` or `Response` at a time.
 
 On the other hand, a "batch collection" of requests and/or responses can be achieved
-with both free clients and a custom `RunClient` instance rather easily, for example 
+with both free clients and a custom `RunClient` instance rather easily, for example
 by using a `Writer [(Request, Response)]` monad.
 
 Here is an example of running our small `test` against a running server:

doc/cookbook/using-free-client/UsingFreeClient.lhs

@@ -318,7 +318,7 @@ genAuthAPI = Proxy
 
 Now we need to bring everything together for the server. We have the
 `AuthHandler Request Account` value and an `AuthProtected` endpoint. To bind these
-together, we need to provide a [Type Family](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/type-families.html)
+together, we need to provide a [Type Family](https://downloads.haskell.org/~ghc/8.8.1/docs/html/users_guide/glasgow_exts.html#type-families)
 instance that tells the `HasServer` instance that our `Context` will supply a
 `Account` (via `AuthHandler Request Account`) and that downstream combinators will
 have access to this `Account` value (or an error will be thrown if authentication
@@ -368,10 +368,10 @@ genAuthMain = run 8080 (serveWithContext genAuthAPI genAuthServerContext genAuth
 $ curl -XGET localhost:8080/private
 Missing auth header
 
-$ curl -XGET localhost:8080/private -H "servant-auth-cookie: key3"
+$ curl -XGET localhost:8080/private -H "Cookie: servant-auth-cookie=key3"
 [{"ssshhh":"this is a secret: Ghédalia Tazartès"}]
 
-$ curl -XGET localhost:8080/private -H "servant-auth-cookie: bad-key"
+$ curl -XGET localhost:8080/private -H "Cookie: servant-auth-cookie=bad-key"
 Invalid Cookie
 
 $ curl -XGET localhost:8080/public

doc/tutorial/Authentication.lhs

@@ -1,9 +1,9 @@
 # Querying an API
 
-While defining handlers that [serve an API](Server.lhs) has a lot to it, querying an API is simpler: we do not care about what happens inside the webserver, we just need to know how to talk to it and get a response back. That said, we usually have to write the querying functions by hand because the structure of the API isn't a first class citizen and can't be inspected to generate the client-side functions.
+While defining handlers that [serve an API](Server.html) has a lot to it, querying an API is simpler: we do not care about what happens inside the webserver, we just need to know how to talk to it and get a response back. That said, we usually have to write the querying functions by hand because the structure of the API isn't a first class citizen and can't be inspected to generate the client-side functions.
 
 **servant** however has a way to inspect APIs, because APIs are just Haskell types and (GHC) Haskell lets us do quite a few things with types. In the same way that we look at an API type to deduce the types the handlers should have, we can inspect the structure of the API to *derive* Haskell functions that take one argument for each occurrence of `Capture`, `ReqBody`, `QueryParam`
-and friends (see [the tutorial introduction](ApiType.lhs) for an overview). By *derive*, we mean that there's no code generation involved - the functions are defined just by the structure of the API type.
+and friends (see [the tutorial introduction](ApiType.html) for an overview). By *derive*, we mean that there's no code generation involved - the functions are defined just by the structure of the API type.
 
 The source for this tutorial section is a literate Haskell file, so first we need to have some language extensions and imports:
 

doc/tutorial/Client.lhs

@@ -1 +1,11 @@
-{-# OPTIONS_GHC -F -pgmF hspec-discover #-}
+module Main where
+
+import qualified JavascriptSpec
+
+import Test.Hspec (Spec, hspec, describe)
+
+main :: IO ()
+main = hspec spec
+
+spec :: Spec
+spec = describe "Javascript" JavascriptSpec.spec

doc/tutorial/test/Spec.hs

@@ -66,7 +66,7 @@ library
       blaze-html   >= 0.9.0.1 && < 0.10
     , blaze-markup >= 0.8.0.0 && < 0.9
     , cookie       >= 0.4.3   && < 0.5
-    , js-jquery    >= 3.2.1   && < 3.3
+    , js-jquery    >= 3.3.1   && < 3.4
     , lucid        >= 2.9.11  && < 2.10
     , random       >= 1.1     && < 1.2
     , servant-js   >= 0.9     && < 0.10
@@ -83,8 +83,6 @@ test-suite spec
   hs-source-dirs: test
   main-is: Spec.hs
   other-modules: JavascriptSpec
-  build-tool-depends:
-    hspec-discover:hspec-discover
   build-depends: base
                , tutorial
                , hspec