| 
Repo Added
 | 
Files
89
 | 
Badge
 
README BADGES
 | 
push
github
Fix detection of inconsistent renames due to sunk values. Thanks to Sergey Kaplun. (cherry picked from commit 811e448da) This commit is a follow-up to the commit 3a2e4847c ("Detect inconsistent renames even in the presence of sunk values."). Due to the reversed assembling order of a trace, all registers are allocated from the bottom of the trace to the top. Furthermore, if the snapshot contains sunk values, IRs for them will contain the `RID_SUNK` after the first processing. If there is another snapshot (with a smaller number) containing this sunk IR, this IR will not be processed during the bloom filter marking in the allocation of the slot that escapes this snapshot (since it is already sunk). Hence, such IRs still may lead to the rename invariant violation like in the aforementioned commit. This patch prevents scanning from stopping when already sunk IR is faced during snapshot processing so bloom filters contain actual information. The disadvantage of this approach is that it assumes that any sunk table-typed IR can't refer to the same table inside it (so there should not be any cycling references in the sunk table). Sergey Kaplun: * added the description and the test for the problem Part of tarantool/tarantool#11055
5696 of 6035 branches covered (94.38%)
Branch coverage included in aggregate %.
2 of 2 new or added lines in 1 file covered. (100.0%)
5 existing lines in 4 files now uncovered.21707 of 23442 relevant lines covered (92.6%)
2962977.73 hits per line
| Coverage | ∆ | File | Lines | Relevant | Covered | Missed | Hits/Line | Branch Hits | Branch Misses | 
|---|
