What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
along with recent policy changes:
- For expression types that are not specifically handled, make sure to
produce a general "unused value" warning, catching a bunch of unused
values in the testsuite.
- For unused operator results, diagnose them as uses of the operator
instead of "calls".
- For calls, mutter the type of the result for greater specificity.
- For initializers, mutter the type of the initialized value.
- Look through OpenExistentialExpr's so we can handle protocol member
references propertly.
- Look through several other expressions so we handle @discardableResult
better.
It's not /really/ an infix operator, but it behaves like a very low
precedence prefix operator. On the other hand, 'try' and 'try!' can
freely move in and out of all the operations we add in fix-its, so
don't bother.
rdar://problem/22259867
Swift SVN r31200
<rdar://problem/21414023> Assertion failure when compiling function that takes throwing functions and rethrows
<rdar://problem/21432429> Calling rethrows from rethrows crashes Swift compiler
<rdar://problem/21427855> Swift 2: Omitting try from call to throwing closure in rethrowing function crashes compiler
Swift SVN r29580
And for "try return", "try throw", and "try let", get even more specific,
with a fix-it to suggest moving the "try" onto the expression.
rdar://problem/21043120
Swift SVN r28862
We parse 'try' as if it were a unary operator allowed on an
arbitrary element of an expr-sequence, but sequence-folding
constrains it to never appear on the RHS of most operators.
We do allow it on the RHS of an assignment or conditional
operator, but not if there's anything to the right which
was not parsed within the RHS.
We do this for assignments so that
var x = try whatever
and
x = try whatever
both work as you might expect.
We do this for conditionals because it feels natural to
allow 'try' in the center operand, and then disallowing it
in the right operand feels very strange.
In both case, this works largely because these operators are
assumed to be very low-precedence; there are no standard
operators which would parse outside the RHS. But if you
create one and use 'try' before it, we'll diagnose it.
Swift SVN r26052
