Add error_recovery.yaml: a place to add scenarios we explicitly want to model in

Add error_recovery.yaml: a place to add scenarios we explicitly want to model in
the front-end.

I added a couple examples from recent conversations as a starting point.

BUG=
R=danrubel@google.com, paulberry@google.com, scheglov@google.com

Committed: https://github.com/dart-lang/sdk/commit/046302f119d5fed5868902aa39c04c813f34f6df

[Siggi Cherem (dart-lang), 2017-08-09 23:43:27]

sigmund@google.com changed reviewers:
+ ahe@google.com, danrubel@google.com, paulberry@google.com, scheglov@google.com

[scheglov, 2017-08-10 00:13:15]

LGTM

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
File pkg/front_end/error_recovery.yaml (right):

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:19: # locations with comments of the form
`/*@error=name*/`, where `name` is a
Do we mark a line, a region, or a single identifier where the error happens?

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:28: - "code completion works inside
initializers of either field."
"inside initializers" seems limiting.
Why not in the type too?

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:32: implementations? Treat it's type as
Object? try to find an LUB for the type?
its
Try

Feel free to ignore this, if the goal is just to provide examples of errors.

Access should pick the first field, with its actual type. There is no much value
anyway - the program already has errors, but we need some simple algorithm that
users will easily understand. "The first one" is easy ;-)

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:37: /*@error=DuplicatedName*/ int field =
bar.length;
I think that the name of the field should be annotated with the error.

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:49: find an LUB for the function type?
Same here - outside of the class only the first is accessible.

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:55: int m() => bar.length;
Same here - the problem is with the name, so the name should be annotated.

[danrubel, 2017-08-10 16:32:33]

LGTM

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
File pkg/front_end/error_recovery.yaml (right):

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:38: /*@error=DuplicatedName*/ String field =
'$foo';
From an test automation standpoint, it would be really nice if the example
indicated the exact range of characters that should be highlighted by the error.
I believe that some downstream tools depend upon the error highlight range.

[Paul Berry, 2017-08-10 16:37:59]

lgtm

[Siggi Cherem (dart-lang), 2017-08-10 18:52:34]

thanks everyone

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
File pkg/front_end/error_recovery.yaml (right):

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:19: # locations with comments of the form
`/*@error=name*/`, where `name` is a
On 2017/08/10 00:13:14, scheglov wrote:
> Do we mark a line, a region, or a single identifier where the error happens?

Good question: let's do a token or region depending on what we know:
 - a token (in front of the token/identifier where the error would be reported)
 - a region starts the same, but then we add an /*@endError*/ comment where the
error region ends.

Added to the doc here.

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:28: - "code completion works inside
initializers of either field."
On 2017/08/10 00:13:14, scheglov wrote:
> "inside initializers" seems limiting.
> Why not in the type too?

Done.

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:32: implementations? Treat it's type as
Object? try to find an LUB for the type?
On 2017/08/10 00:13:14, scheglov wrote:
> its
> Try
> 
> Feel free to ignore this, if the goal is just to provide examples of errors.
> 
> Access should pick the first field, with its actual type. There is no much
value
> anyway - the program already has errors, but we need some simple algorithm
that
> users will easily understand. "The first one" is easy ;-)

Sounds good. I adopted your suggestion.

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:37: /*@error=DuplicatedName*/ int field =
bar.length;
On 2017/08/10 00:13:14, scheglov wrote:
> I think that the name of the field should be annotated with the error.

Done.

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:38: /*@error=DuplicatedName*/ String field =
'$foo';
On 2017/08/10 16:32:33, danrubel wrote:
> From an test automation standpoint, it would be really nice if the example
> indicated the exact range of characters that should be highlighted by the
error.
> I believe that some downstream tools depend upon the error highlight range.

Good suggestion. Done. Added /*@errorEnd*/ for this.

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:49: find an LUB for the function type?
On 2017/08/10 00:13:14, scheglov wrote:
> Same here - outside of the class only the first is accessible.

Done.

https://codereview.chromium.org/2998743002/diff/1/pkg/front_end/error_recover...
pkg/front_end/error_recovery.yaml:55: int m() => bar.length;
On 2017/08/10 00:13:14, scheglov wrote:
> Same here - the problem is with the name, so the name should be annotated.

Done.

[Siggi Cherem (dart-lang), 2017-08-10 18:52:53]

Description was changed from

==========
Add error_recovery.yaml: a place to add scenarios we explicitly want to model in
the front-end.

I added a couple examples from recent conversations as a starting point.

BUG=
==========

to

==========
Add error_recovery.yaml: a place to add scenarios we explicitly want to model in
the front-end.

I added a couple examples from recent conversations as a starting point.

BUG=
R=danrubel@google.com, paulberry@google.com, scheglov@google.com

Committed:
https://github.com/dart-lang/sdk/commit/046302f119d5fed5868902aa39c04c813f34f6df
==========

[Siggi Cherem (dart-lang), 2017-08-10 18:52:54]

Committed patchset #2 (id:20001) manually as
046302f119d5fed5868902aa39c04c813f34f6df (presubmit successful).