dart-lang / dart-lang/language

[grammar] `selector`/`typeArgument`-related ambiguity.

Open
#3,039 2 comments 0 reactions 1 assignee Claimed by @eernstg View on GitHub
Dominant language
TeX
Stars
2.9k
Forks
239
Avg merge
2d 18h
Merged PRs (30d)
14

Description

A recent change made it possible to give function invocations type arguments without having to invoke the function with value arguments.

```dart
void main() {
final a = foo;
print(a);
}

void foo() {}
```
It looks like this change has lead to a new production `typeArguments` in the selector production rule in the ANTLR-based grammar spec.

https://github.com/dart-lang/sdk/blob/b06b994a4eea9eb88ef5b40060bd8ff16b848868/tools/spec_parser/Dart.g#L971-L982

It looks like the language spec grammar snippets have not yet been adjusted to reflect this change i.e. the `selector` grammar snippet does not contain a `typeArguments` production.

https://github.com/dart-lang/language/blob/a6209672d4bc11442ef64561dc612edb7accfe5f/specification/dartLangSpec.tex#L16270-L16277

If we were to add a `typeArguments` production to the `selector` production rule, then I think this would give `id()` 2 parse trees:

```
...
1. primary selector*
identifier selector selector
identifier typeArguments argumentPart
identifier typeArguments typeArguments? arguments
identifier typeArguments null arguments
'id' '' '()'

...
2. primary selector*
identifier selector
identifier argumentPart
identifier typeArguments arguments
'id' '' '()'
```

I'm wondering what a grammar that does not have this ambiguity would look like?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.