feat: support decorated expressions

[aspeddro]

See reanalyze exampes

@local
call()

(source_file [0, 0] - [2, 0]
  (ERROR [0, 0] - [1, 6]
    (decorator [0, 0] - [1, 6]
      (decorator_identifier [0, 1] - [0, 6])
      (ERROR [1, 0] - [1, 4]
        (ERROR [1, 0] - [1, 4]))
      (decorator_arguments [1, 4] - [1, 6]))))

[nkrkv]

Call expression is definitely an expression, not a declaration.

I understand the intent, but it should be structured in another way I guess.

[aspeddro]

I moved to call_expression to _decorated_statement

[aspeddro]

Maybe we should use expression_statement here. Since decorators/attributes can appear anywhere.

[nkrkv]

It is fine now. Thank you!

Yes, decorators can appear anywhere basically. In that sense they might be implemented as comments, for example. But in this case they would appear as siblings to the parts of code they decorate and would not participate in, for example, broader/narrower selection. So I think it is better to eventually come to the grammar where all possible cases are covered semantically. Your addition improves the situation following this way 👍