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
