[3.7.1] VM abort gives wrong line

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: [3.7.1] VM abort gives wrong line

Re: [3.7.1] VM abort gives wrong line

by Graf Zahl » Fri Jan 11, 2019 10:37 am

Why should I object?

Re: [3.7.1] VM abort gives wrong line

by _mental_ » Fri Jan 11, 2019 10:11 am

In order to be sure there will be no objections, I made this PR with the fix.

Re: [3.7.1] VM abort gives wrong line

by _mental_ » Wed Jan 09, 2019 6:59 am

Curiously enough, it works like a raw string literal. Also, we can create kinda multi-line comments inside functions like this as long as it doesn't include double quote.

Code: Select all

// ... code ...
"
cool
multi-line
comment
";
// ... code ...
Unfortunately, it's treated as a single line screwing error/warning reporting. Outside of this issue, it's OK to keep it as is in my opinion.
The topic's title is a bit misleading because this has nothing to do with a runtime exception handling.

Re: [3.7.1] VM abort gives wrong line

by Graf Zahl » Wed Jan 09, 2019 6:23 am

I thought so, too. And obviously the parser isn't prepared for that kind of token.

Re: [3.7.1] VM abort gives wrong line

by _mental_ » Wed Jan 09, 2019 5:51 am

The discrepancy is caused by this multi-line thing.

I was surprised that it's correct syntax at all. I thought every line should be wrapped with double quotes like in C/C++.

[3.7.1] VM abort gives wrong line

by Matt » Wed Jan 09, 2019 2:21 am

Still happens on cb4548a.

1. Try to run this commit of HD.
2. Read the line number given for "Self pointer used in ambiguous context; VM execution may abort!"

Expected: Line 675
Actual: Line 663

Setting vm_jit in the command line has no effect on this output.

First noticed on Windows build but replicated on own Debian compile.
(Not sure if Windows build was offsetting the line # in the same way)

Top