Fix more error cases

[chqrlie]

• fix more cases of missing sf->cur_pc.
• use more precise error messages for number conversion methods
• add test cases in test_builtin.js

[saghul]

LGTM with a question. Now that you covered all cases, does it make sense to still set cur_pc in the exception: label? If not, shall we skip it and add a check-abort?

[saghul]

Weird, how did this come back?

[chqrlie]

I don't know. I am investigating this, but won't have much time until tonight.
We should have a more complete emulation of the v8 error handling:

• the stack trace should be computed by a v8 specific function Error.captureStackTrace, which is non-standard but is quite handy for introspection. It takes an object as argument and sets its stack property to a the stack trace string, and an optional second argument which is an array of frames.

[saghul]

I actually already implemented that here in this fork! :-)

555d837
4c929c5

[saghul]

Very nice!

[chqrlie]

LGTM with a question. Now that you covered all cases, does it make sense to still set cur_pc in the exception: label? If not, shall we skip it and add a check-abort?

Yes, sf->cur_pc must still be set in the exception: label because it is needed for the non recursive cases where an exception is thrown directly from JS_CallInternal or indirectly by a c function without recursing to a javascript function.

Conversely, we might want to initialize sf->cur_pc to pc instead of null to avoid crashing in production on a case where the synchronisation is missing and keep the sf->cur_pc = NULL as an ifdef's debugging alternative for a specific CI target.

[saghul]

Conversely, we might want to initialize sf->cur_pc to pc instead of null to avoid crashing in production on a case where the synchronisation is missing and keep the sf->cur_pc = NULL as an ifdef's debugging alternative for a specific CI target.

TBH I'd rather abort hard so it's easy to catch, fix and be done with it...

[chqrlie]

Conversely, we might want to initialize sf->cur_pc to pc instead of null to avoid crashing in production on a case where the synchronisation is missing and keep the sf->cur_pc = NULL as an ifdef's debugging alternative for a specific CI target.

TBH I'd rather abort hard so it's easy to catch, fix and be done with it...

In the debug target, that's fine, but in the production version, why abort when there is no user visible downside?