jq 1.6 different (incorrect?) behavior for tonumber? // tostring compared to jq 1.5 #1885
Labels
Comments
|
Thanks for the report! |
|
Oddly this is fixed in my |
|
Note that the problem seems to have nothing to do with |
|
@pkoppstein yes, it's probably another manifestation of #1859. |
|
hi , @nicowilliams This situation is also handled incorrectly, so This bug may not have been fixed perfectly |
|
@nicowilliams Thanks for your work，The result of the current |
|
@Alanscut thank you for testing it! |
|
Any chance of getting a fix for this released as this is breaking behaviour for jq-1.6? |
nicowilliams
added a commit
to nicowilliams/jq
that referenced
this issue
Jul 24, 2023
Close jqlang#1885, jqlang#2140, jqlang#2011, jqlang#2220, jqlang#2485, 2073 Rename the FORK_OPT opcode to TRY_BEGIN, add a TRY_END opcode, and wrap errors when raising through a TRY_END so that they will not be caught by the matching TRY_BEGIN. Now a `try exp catch handler` expression generates code like: TRY_BEGIN handler <exp> TRY_END JUMP past_handler handler: <handler> past_handler: ... On backtrack through TRY_BEGIN it just backtracks. If anything past the whole thing raises when <exp> produced a value, then the TRY_END will catch the error, wrap it in another, and backtrack. The TRY_BEGIN will see a wrapped error and then it will unwrap and re-raise the error. If <exp> raises, then TRY_BEGIN will catch the error and jump to the handler, but the TRY_BEGIN will not stack_save() in that case, so on raise/backtrack the TRY_BEGIN will not execute again (nor will the TRY_END).
emanuele6
pushed a commit
that referenced
this issue
Jul 24, 2023
Close #1885, #2140, #2011, #2220, #2485, #2073 Rename the FORK_OPT opcode to TRY_BEGIN, add a TRY_END opcode, and wrap errors when raising through a TRY_END so that they will not be caught by the matching TRY_BEGIN. Now a `try exp catch handler` expression generates code like: TRY_BEGIN handler <exp> TRY_END JUMP past_handler handler: <handler> past_handler: ... On backtrack through TRY_BEGIN it just backtracks. If anything past the whole thing raises when <exp> produced a value, then the TRY_END will catch the error, wrap it in another, and backtrack. The TRY_BEGIN will see a wrapped error and then it will unwrap and re-raise the error. If <exp> raises, then TRY_BEGIN will catch the error and jump to the handler, but the TRY_BEGIN will not stack_save() in that case, so on raise/backtrack the TRY_BEGIN will not execute again (nor will the TRY_END).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
jq-1.6 behaves differently (and as I read the manual, incorrectly) when running map_values with a filter which includes an alternate
//.To Reproduce
Expected behavior
Expected jq-1.5 output to appear in both cases
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: