Convert DecodingErrors thrown from request handling code to HTTP 400 … ( #161) ### Motivation The library does not gracefully handle when clients send requests with malformed request bodies, parameters, etc. If a client sends a request that for example is missing a required field or has a field that cannot be converted to the correct type, the server should respond with a `400` indicating to the client that **they** have done something wrong. Instead, the library throws a `DecodingError` which propagates all the way up resulting in a `500` response which incorrectly tells the client that something went wrong on the server. ### Modifications * Added a layer of handling to each call that is made to decode request objects which wraps `DecodingErrors` into `RuntimeErrors`. * Make `ServerError` conform to `HTTPResponseConvertible` * Modify `ErrorHandlingMiddleware` to first check if the underlying error conforms to `HTTPResponseConvertible` and if not use the values from `ServerError`. This allows the `HTTPResponseConvertible` values set in a `RuntimeError` to be honoured after the `RuntimeError` is transformed into a `ServerError`. ### Result Since `RuntimeError` conforms to `HTTPResponseConvertible` these errors will get converted to `400` responses by the `ErrorHandlingMiddleware`. This isn't a perfect solution because consumers of the library have to opt-in to the `ErrorHandlingMiddleware` to avoid returning `500`. ### Test Plan * Added unit tests for each modification. * Verified in my own service that with this change malformed requests get converted into `400` responses. --------- Co-authored-by: colin-dignazio <colin_dignazio@apple.com> Co-authored-by: Honza Dvorsky <honza@apple.com>

Fix encoding of OpenAPI{Object,Value}Container to allow multiple enco… …dings in anyOf/allOf (#156) ### Motivation Fixes apple/swift-openapi-generator#808. More background: We used to use `singleValueContainer()`, provided by Codable, to encode not just primitive values, but also composite values like objects and arrays. This works in _most_ cases, but not when you have an `anyOf` (or an `allOf`), which contains more than 1 of these types (`OpenAPIValueContainer` or `OpenAPIObjectContainer`). When it hits that case, it crashes at runtime, because you can't encode multiple composite types into a single encoder using `singleValueContainer()`. However, you can do that when using the proper `container(keyedBy:)` and `unkeyedContainer()` APIs, as that way you're not overwriting the value that's already there, but amending it. ### Modifications Improve the encoding and decoding logic of `OpenAPIValueContainer` and `OpenAPIObjectContainer` to use the more appropriate Codable APIs when coding composite types, like objects and arrays. ### Result Now we can have an anyOf/allOf with multiple of these types, and they encode/decode correctly. I also verified that the original example reported by the user works with this patch. ### Test Plan Added more unit tests and ensured all still pass, also verified that Swift OpenAPI Generator's tests pass when pointed at this patched version of Runtime.

Add support for Windows (#148) CoreFoundation isn't API on Windows, so compile it out in that case. All tests pass with these changes. Co-authored-by: Honza Dvorsky <honza@apple.com>

Only apply standard swift settings on valid targets (#145) Only apply standard swift settings on valid targets. The current check ignores plugins but that is not comprehensive enough.

[CI] Enable Linux nightly main on PRs (#137) ### Motivation PR CI was missing testing with nighly Linux toolchains from main. ### Modifications Enable nightly toolchain CI as well. ### Result More test coverage on PRs. ### Test Plan See this PR's CI if this works or if we need more changes.

Refactor URIDecoder/URIParser to improve handling of the deepObject s… …tyle (#127) ### Motivation As part of apple/swift-openapi-generator#259, adding deepObject parameter style support, the initial PR wasn't complete. And once we dug more into it, turns out the original implementation of the URIDecoder/URIParser didn't really lend themselves well for handling deepObject, and the recent additions of supporting arrays within dictionaries (#120) further confused the implementation. ### Modifications Refactored URIParser/URIDecoder with a clearer understanding of the current requirements. It's now much easier to follow and embraces the fact that each of the 7 variants of URI coding we support (form exploded, form unexploded, simple exploded, simple unexploded, form data exploded, form data unexploded, and now deepObject exploded) are similar, but still different in subtle ways. This new implementation doesn't try as hard to share code between the implementations, so might at first sight appear to duplicate code. The original implementation had many methods with many configuration parameters and utility methods with a high cyclomatic complexity, which made it very hard to reason about. We did away with that. While there, I also made some minor improvements to the serialization path, which allows cleaner round-tripping tests. ### Result A more maintainable and more correct URI decoder/parser implementation. ### Test Plan Added many more unit tests that test the full matrix of supported styles and inputs. --------- Co-authored-by: Si Beaumont <simonjbeaumont@gmail.com>

Add Mac Catalyst support (#124) 

Custom JSON encoding options (#112) 

Improved encoding of NSNumber in OpenAPIValueContainer (#110) Improved encoding of NSNumber in OpenAPIValueContainer ### Motivation When getting CoreFoundation/Foundation types, especially numbers, they automatically bridge to Swift types like Bool, Int, etc. That casting is pretty flexible, and allows e.g. casting a number into a boolean, which isn't desired when encoding into JSON, as `false` and `0` represent very different values. Previously, we relied on the automatic casting to know how to encode values, however that produced incorrect results in some cases. ### Modifications Add explicit handling of CF/NS types and try to encode using that new method before falling back to testing for native Swift types. This ensures that the original intention of the creator of the CF/NS types doesn't get lost in encoding. ### Result Correct encoding into JSON of types produced in the CF/NS world, like JSONSerialization. ### Test Plan Added unit tests. Reviewed by: simonjbeaumont Builds: ✔︎ pull request validation (5.10) - Build finished. ✔︎ pull request validation (5.9) - Build finished. ✔︎ pull request validation (5.9.0) - Build finished. ✔︎ pull request validation (api breakage) - Build finished. ✔︎ pull request validation (docc test) - Build finished. ✔︎ pull request validation (integration test) - Build finished. ✔︎ pull request validation (nightly) - Build finished. ✔︎ pull request validation (soundness) - Build finished. #110

[Runtime] Add support of deepObject style in query params (#100) ### Motivation The runtime changes for: apple/swift-openapi-generator#259 ### Modifications Added `deepObject` style to serializer & parser in order to support nested keys on query parameters. ### Result Support nested keys on query parameters. ### Test Plan These are just the runtime changes, tested together with generated changes. --------- Co-authored-by: Honza Dvorsky <honza@apple.com>