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

Some Compiler exceptions don't show the filename correctly. #3018

Closed
Dunbaratu opened this issue Sep 15, 2021 · 1 comment · Fixed by #3043
Closed

Some Compiler exceptions don't show the filename correctly. #3018

Dunbaratu opened this issue Sep 15, 2021 · 1 comment · Fixed by #3043
Labels
bug Weird outcome is probably not what the mod programmer expected.

Comments

@Dunbaratu
Copy link
Member

Dunbaratu commented Sep 15, 2021

Example: Consider one file calling another file like so:

// THIS is "prog1.ks", which runs prog2.
run prog2.ks.
// This is "prog2.ks" where the error really is.

// This scientific notation is too big to fit in a double, and kOS does produce an error
// for that.
// BUT because the syntax of digits, 'e', more digits, is is perfectly valid in the grammar,
// this doesn't get caught in parsing, instead Compiler.cs complains when analising
// the parsed tree:
set x to 99e999999999999.

Then you run these by doing this:

run prog1.ks.

When you do this (errors that Compiler.cs throws instead of the parser throwing them), sometimes the error message will claim the calling program that called the inner program is where the error is, and that's not true.

In the above example, the error message will claim it's prog1.ks that is in error, not prog2.ks.

The reason is because the exception catcher that logs the error assumes the error is the fauilt of the opcode instruction that was being executed when the error happened, but that opcode is the place where the caller loaded the program that wouldn't compile.

@Dunbaratu Dunbaratu added the bug Weird outcome is probably not what the mod programmer expected. label Sep 15, 2021
@Dunbaratu
Copy link
Member Author

Dunbaratu commented Sep 15, 2021

I was trying to "fix" this problem that I thought I had done wrong in my new mask builtins check, until I tested and found the same problem exists anywhere a compile problem is not detected by the parser but is instead detected by Compiler.cs after the parser has built the parse tree and Compiler.cs is visiting the nodes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Weird outcome is probably not what the mod programmer expected.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant