Ran
|
Jobs
1
|
Files
89
|
Run time
2s
|
Badge
README BADGES
|
push
github
Fix predict_next() in parser. Reported by Sergey Kaplun. (cherry-picked from commit caf7cbc57) Assume, we have the following Lua code: | local _ | for _ in (nil):foo() do end The first part of the bytecode emitted for it is the following: | 0001 KNIL 0 1 | 0002 MOV 2 1 | 0003 TGETS 1 1 0 ; "foo" | 0004 CALL 1 4 2 The `0001 KNIL` is a result of merging two `KPRI` instructions: one for the local variable, one for the slot with `nil` object. During parsing in `predict_next()` the second `MOV` bytecode is examined to set `pairs` or `next` local variable. But, as far as it moves `nil` value, that isn't an actual variable and has no the name, so this leads to the crash. This patch adds a check to be sure that `RD` (see <src/lj_bc.h>) in the `MOV` bytecode is an actual variable. Sergey Kaplun: * added the description and the test for the problem Part of tarantool/tarantool#8825 Reviewed-by: Maxim Kokryashkin <m.kokryashkin@tarantool.org> Reviewed-by: Sergey Bronnikov <sergeyb@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org>
5326 of 5963 branches covered (0.0%)
Branch coverage included in aggregate %.
20452 of 23278 relevant lines covered (87.86%)
1291476.03 hits per line
Lines | Coverage | ∆ | File |
---|---|---|---|
1 |
95.68 |
-0.05% | src/lj_record.c |
6 |
94.74 |
-4.31% | src/lj_str.c |
ID | Job ID | Ran | Files | Coverage | |
---|---|---|---|---|---|
1 | 5999839971.1 | 89 |
88.16 |
GitHub Action Run |
Coverage | ∆ | File | Lines | Relevant | Covered | Missed | Hits/Line | Branch Hits | Branch Misses |
---|