You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Dunbaratu
added
the
bug
Weird outcome is probably not what the mod programmer expected.
label
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.
Example: Consider one file calling another file like so:
Then you run these by doing this:
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, notprog2.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.
The text was updated successfully, but these errors were encountered: