[clang] [Clang] Fix parsing of expressions of the form (T())[/*...*/] (PR #140053)

[via cfe-commits]

cor3ntin wrote:

Copy of a mail I sent to CWG
---

This issue comes from an old LLVM issue reported by Richard, which I thought I could fix in a few minutes.

I was wrong.

Consider the following:
```cpp
(S())[]->A<int>; // #1

(S())[]->A<int> {return {};}; //#2
```

**<https://gcc.godbolt.org/z/a8j1ac9fj>**\
This is yet another flavor of ambiguity caused by declarator syntax, which I don't think we have wording to resolve.

#1 is a parenthesized constructor call, followed by\
calls to some `operator[]`, `operator->`

#2 is an (invalid) C-cast of a lambda expression.

You would think that it is easy to tell these things apart because of the opening brace in #2.

However, this forces us to decide if the entity after the arrow is a type or an expression.\
We also can't look into whatever the declaration context of the\
type of result of a potential operator-> call that we have not resolved yet.

There is no clever way to balance the tokens as could be a valid\
binary operator. eg

`(S())[]->A < some expression;`

Trying to determine if the thing after -> is a type may force us to do template instantiations.\
So I think we need a rule in the spirit of <https://eel.is/c++draft/dcl.ambig.res#2>to deal with that case

We should resolve that in favor of the thing after the arrow\
being a type, and forcing the expression to be a lambda, even though it might not be a valid one.

I think other cases can be resolved syntactically,\
including `(S())[] < expr; // We can tell expr is not a template parameter`

No compiler gets that right currently, both GCC (afaict) and Clang assume [ after as cast is always a lambda

https://github.com/llvm/llvm-project/pull/140053