tarantool / tarantool / 6094605099

88%

push

github

box: get rid of the slowpath comparator unreachable branch

The tuple_compare_slowpath comparator had unreachable
branch under this condition: `key_def->part_count == 1
&& part->fieldno == 0 && (!has_json_paths || part->path
== NULL)`. The condition will never be true in the
function context.

It has been introduced in the commit
c8b87dc76 ("Speed up
tuple_compare()."), when there was no sqeuential
comparators, and so it was reasonable at that moment.
But since the sequential comparators had been introduced
in the commit
78102868c ("Don't store
offsets for sequential multi-parts keys") the condition
became permanently falsy.

There're two ways it can be true:
1. `key_def->part_count == 1 && part->fieldno == 0 &&
   !has_json_paths`
2. `key_def->part_count == 1 && part->fieldno == 0 &&
   has_json_paths && part->path == NULL`

Condition 1 will never happen because if we have a key
starting from `fieldno = 0` with any part count
following and without JSON paths, then it is compared
using `tuple_compare_sequential` instead.

Proof:
1. The key is sequential if and only if it does not have
   JSON paths and for all key parts
   `index_def->parts[i].fieldno == i`.
2. The `key_def->part_count == 1 && part->fieldno == 0
   && !has_json_paths` condition fully satisfies this
   condition.
3. The `tuple_compare_slowpath` is only set as a
   comparator if the key is not sequential. Proof:

   The only places the comparator is set are:
   - `key_def_set_compare_func_fast` under the
     `!is_sequential` condition.
   - `key_def_set_compare_func_plain` under the
     `!key_def_is_sequential` condition.
   - `key_def_set_compare_func_json`, which is only
     called under `def->has_json_paths` condition, which
     conflicts with the `!has_json_paths` condition.

Condition 2: has JSON path means we have `path`
parameter in the index definition, but the following
condition requires the path to be `NULL`, w... (continued)

64183 of 115869 branches covered (0.0%)

1 of 1 new or added line in 1 file covered. (100.0%)

96030 of 111200 relevant lines covered (86.36%)

2596473.64 hits per line