Parse failure with < after a cast destination type.

[simanerush]

Description
When dealing with cast destination type and a < operator after it, the compiler assumes that the generic arguments list is going to follow the < and produces an expected type error.

Steps To Reproduce
Steps to reproduce the behavior:

1. Launch Swift.
2. Run let _ = 1 as Int16 < 7.
3. Observe the expected type error.

Expected behavior
There should be no expected type error, since < in this context is not supposed to be followed by a generic arguments list.

Environment

• OS: macOS 12.4
• Xcode Version: 13.4

Additional context
I fixed issue #43053 which addresses similar problem, but with the<< operator.

[CodaFi]

This is a fun cross-language disambiguation problem. Consider the (related) classical ambiguous parsing example:

f(a<b,c>(d))

Is a<b,c> meant to be a specialized generic type that is having its initializer invoked with argument d, or are a, b, c, and d actually a fragment of two boolean arguments to f that are being compared via the < and > operators? Bear in mind that both answers are valid parser productions if we parse without retaining a bunch of contextual state (e.g. a symbol table) or performing some amount of unbounded lookahead.

For some context, Rust has the exact same problem.

[tbkka]

That same Rust thread describes the C# heuristic, which makes a lot of sense to me.

[CodaFi]

The current Rust-y answer of using lookahead to emit an extremely helpful diagnostic also works here. The C# solution doesn't feel right to me not just because it fails the "some amount of unbounded lookup" test, but because it precludes the language adopting non-type type parameter arguments without some extra disambiguating tokens.

error: `<` is interpreted as a start of generic arguments for `i16`, not a shift
 --> <source>:3:16
  |
3 |     num as i16 << 7
  |                ^^ - interpreted as generic arguments
  |                |
  |                not interpreted as shift
  |
help: try shifting the cast value
  |
3 |     (num as i16) << 7
  |     +          +

[simanerush]

@CodaFi Thank you for this detailed response. I understand the first problem with some ambiguity concerning <, but your second message is more concerned with <<. One of my currently opened PRs silences the expected type diagnostics in that case. Now, I'm wondering if we even need to silence that if for example Rust doesn't do it but emits helpful diagnostics. Can you please take a look at this PR which addresses << issue? #60088