Fix exponential blowup parsing pathological files

[CyrusNajmabadi]

Fixes #73789

[CyrusNajmabadi]

@dotnet/roslyn-compiler This is ready for review. Tnx.

[cston]

The test case should be a minimal repro to hit the specific parsing issue.

[cston]

An attribute can never appear inside an attribute declaration in the language.

It looks like the grammar allows an attribute argument expression to contain a lambda expression with an attribute on the lambda. This is only disallowed in binding because the lambda expression does not represent a constant, correct?

Example: sharplab.io

[A([A]() => 1)] // error CS0182: attribute argument must be a constant ...
class Program
{
}

[CyrusNajmabadi]

This is only disallowed in binding because the lambda expression does not represent a constant, correct?

Correct. This is never going to be legal code. So the decision here is to prevent it at parsing time vs binding time (and only for the attributed lambda case). That way we can avoid pathlogical parsing conditions.

Pros: Pathological parsing cases don't go off hte rails in speculative parsing.
Cons: A syntactically legal (but semantically illegal) case errors earlier and produces a worse parse tree.

This seems like an easy justification to make. The impact of speculative parsing here is enormous (it literally hangs vs/compiler). While the impact of disallowing an attributed-lambda in an attribute at parsing time is extremely minor. Who is realistically writing that? And, even if they do, getting a different syntactic error is fine.

[cston]

(since attributes can not be on lambda expressions)

Attributes can be applied to lambda expressions.

[CyrusNajmabadi]

Attributes can be applied to lambda expressions.

Not legally. That's my point here. Attributes can't ever actually be used within an attribute argument itself.

[CyrusNajmabadi]

@cston i think all feedback responded to.

[CyrusNajmabadi]

@dotnet/roslyn-compiler for another set of eyes. thankx :)

[CyrusNajmabadi]

note: this test no longer validates https://github.com/dotnet/roslyn/pull/73788/files#diff-a655d393d9799eabace5e5109383232749be8052f1fd825fc52b9f170908e838R11891. We can remove that codee and this test passes (though the original user report still hangs the compiler).

[CyrusNajmabadi]

@dotnet/roslyn-compiler for another set of eyes. thanks.

[CyrusNajmabadi]

@jaredpar when you have a minute.

[jaredpar]

@jaredpar when you have a minute.

So never? ;)

[CyrusNajmabadi]

So never? ;)

We'll just pencil it for Monday 6/12 at never o'clock.