Improve Error Reporting: no expression in computation expression

[isaacabraham]

What

Consider the following code sample:

let foo() =
    async {
        let! result = async { return 0 }
    }

and the associated error message, error FS0010: Unexpected symbol '}' in expression.

Why

The error message doesn't help understand why the error has occurred, nor given any guidance on how to fix it. In addition, the error occurs on the final line (with the }) rather than with the let!. See here for a sample of a real-world issue caused by this.

How

Ending the block with a normal let gives a much better error

let foo() =
    async {
        let result = async { return 0 }
    }

gives The block following this 'let' is unfinished. Every code block is an expression and must have a result. 'let' cannot be the final code element in a block. Consider giving this block an explicit result. (although I think that this message could still be improved...).

How about this for let!s:

'let!' cannot be the final code element in a computation expression block. Consider replacing the use of let! with return! if this is the final expression in the block, or returning some value after this expression, or executing either a do! (or unit-returning) expression after this expression.

[cartermp]

I like the suggestion, but I'd prefer it to be a bit shorter since we're showing too many options:

'let!' cannot be the final code element in a computation expression block. Consider giving this block an explicit result to return.

[isaacabraham]

@cartermp yep. Maybe keep the return! though as that's a (as far as I can tell) guaranteed and simple fix?

'let!' cannot be the final code element in a computation expression block. Consider replacing the use of let! with return!, or returning another explicit result from this block.

[cartermp]

Sounds good.

[KathleenDollard]

What do we need to do to move this out of "needs discussion" into "up for grabs"?

[cartermp]

I think this one could be considered up for grabs. The challenge here would be in detecting the pattern rather than emitting the parse error.

[baronfel]

Note to potential implementors - consider using this fantomas tools link to help you find the correct parse tree shapes on which to give the error.