Add the inference rules for throw error types

Author: amartini51

TSPL.docc/ReferenceManual/Expressions.md

@@ -922,13 +922,13 @@ explicitly marks a closure as throwing or asynchronous.
 }
 ```
 
-If the body of a closure includes a try expression,
+If the body of a closure includes a `throws` statement or a `try` expression
+that isn't nested inside of a `do` statement with exhaustive error handling,
 the closure is understood to be throwing.
-<!-- XXX
-The same rule to infer the thrown error type
-applies to closures as to functions.
--->
-Likewise, if it includes an await expression,
+If a throwing closure throws only errors of a single type,
+the closure is understood as throwing that error type;
+otherwise it's understood as throwing `any Error`.
+Likewise, if the body includes an `await` expression,
 it's understood to be asynchronous.
 
 There are several special forms

TSPL.docc/ReferenceManual/Statements.md

@@ -889,13 +889,31 @@ do throws(<#type#>) {
 }
 ```
 
+<!-- XXX Is "do throws { }" allowed? -->
+
 If the `do` statement includes a `throws` clause,
-the `do` block can throw only errors of the specified type.
-The *type* must be a concrete type that conforms to the `Error` protocol,
+the `do` block can throw errors of only the specified *type*.
+The *type* must be either
+a concrete type that conforms to the `Error` protocol,
 an opaque type that conforms to the `Error` protocol,
 or the boxed protocol type `any Error`.
 If the `do` statement doesn't specify the type of error it throws,
-that type is implied to be `any Error`.
+the error type is inferred as follows:
+
+- If every `throws` statement and `try` expression in the `do` code block
+  is nested inside of an exhaustive error handling mechanism,
+  then the `do` statement is inferred as nonthrowing.
+
+- If the `do` code block contains code that throws
+  errors of only a single type
+  outside of exhaustive error handling,
+  then the `do` statement is inferred as throwing that concrete error type.
+
+- If the `do` code block contains code that throws
+  errors of more than a single type
+  outside of exhaustive error handling,
+  then the `do` statement is inferred as throwing `any Error`.
+
 For more information about working with errors that have explicit types,
 see <doc:ErrorHandling#Specifying-a-Concrete-Error-Type>.