range expressions (a..b) interact weirdly with operator precedence

[dgrunwald]

.. acts like it has extremely high operator precedence in the left-hand-side, and extremely low precedence in the right-hand-side.

b && r == 1..2 gets parsed as b && (r == (1..2))
r == 1..2 && b gets parsed as r == (1..(2 && b))

I'm not sure what the proper operator precedence should be. It's a bit tricky to get this correct in the grammar as .. is valid as prefix, infix and suffix operator.

Fixing this bug will probably require a breaking change. (I'm not sure if we plan to stabilize slicing_syntax for 1.0)

[dgrunwald]

Actually, I was mistaken, and my 'gets parsed as' above is wrong. It just has extremely low operator precedence on both sides. There's some weirdness with the prefix version, though.