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

Bizzare error for invalid if #512

Closed
Y-Less opened this issue Apr 15, 2020 · 3 comments
Closed

Bizzare error for invalid if #512

Y-Less opened this issue Apr 15, 2020 · 3 comments

Comments

@Y-Less
Copy link
Member

Y-Less commented Apr 15, 2020

Issue description:

Missing the brackets on an if statement gives an error about invalid subscripts:

error 028: invalid subscript (not an array or too many subscripts): "var"
error 029: invalid expression, assumed zero
warning 215: expression has no effect
error 001: expected token: ";", but found "-end of file-"

This would be a far better error:

error 001: expected token: "(", but found "-identifier-"

Minimal complete verifiable example (MCVE):

main()
{
	new var;
	if var
	{
	}
}

Workspace Information:

  • Compiler version:
  • Command line arguments provided (or sampctl version):
  • Operating System:

3.10.10

@stale
Copy link

stale bot commented Aug 29, 2020

This issue has been automatically marked as stale because it has not had recent activity.

@stale stale bot added the state: stale label Aug 29, 2020
@Daniel-Cortez
Copy link
Contributor

Daniel-Cortez commented Aug 29, 2020

Since there are no parentheses, the compiler expects keyword *then after the if control expression, e.g.:

if var *then *begin /* ... */ *end

or

if var *then { /* ... */ }

I'm not sure how many people actually use this alternative syntax, but it's still valid in our version of Pawn (IIRC it was removed only in Pawn 3.3).

Anyway, since keyword *then is missing in the example as well, the compiler treats the opening { as a continuation of the control expression, as if var was subscripted as a byte array, hence the "invalid subscript" error.
In other words, the compiler works correctly.

But I think we should probably consider removing *then, *begin and *end, as it was done in 3.3, because these keywords may complicate diagnostics, as it was well shown in the 1'st post (and also because they're ugly).

@stale stale bot removed the state: stale label Aug 29, 2020
@Daniel-Cortez
Copy link
Contributor

@pawn-lang As I explained in the above post, the compiler works correctly, so this issue should probably be closed.

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

3 participants