Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fail earlier and better on doomed parses #10

Open
masak opened this issue Jan 19, 2015 · 2 comments
Open

Fail earlier and better on doomed parses #10

masak opened this issue Jan 19, 2015 · 2 comments

Comments

@masak
Copy link
Owner

masak commented Jan 19, 2015

I just fixed two specific cases, namely when my and sub are followed by a non-identifier. Instead of backtracking and trying other rules (usually statement:expr, which is very general), the parser should just give up directly with a <.panic> call.

See these two commits for inspiration on how to do this.

This issue can be closed when the parser has been combed for other opportunities like this, and <.panic> calls installed. As much as possible, each such <.panic> should be accompanied by a test in t/syntax/errors.t.

@masak
Copy link
Owner Author

masak commented Sep 18, 2017

I'd say #94 is really only a sub-case of this one.

@masak
Copy link
Owner Author

masak commented May 16, 2019

This issue now basically means "have decent compiler error messages", which I still want, but...

...one aspect of that is to think about "secondary source locations". That is, when a call turns out to be impossible, also link to (and show file/line information for) the function(s) whose parameters that call's arguments don't match up with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant