vitessio/vitess · error

unreachable

Error message

unreachable

What it means

The LIKE/regex expression compiler handles each match-type case (LIKE, NOT LIKE, REGEXP, etc.) and treats any remaining value as impossible, hence 'unreachable'. Panicking here means a match operator kind outside the enumerated set reached the switch, indicating the IR contains a match expression variant the compiler does not implement.

Source

Thrown at go/vt/vtgate/evalengine/expr_compare.go:598

			c.asm.In_slow(c.env.CollationEnv(), expr.Negate)
		}

		return ctype{Type: sqltypes.Int64, Col: collationNumeric, Flag: flagIsBoolean | (nullableFlags(lhs.Flag) | (rt.Flag & flagNullable))}, nil
	case *BindVariable:

		if rhs.Type != sqltypes.Tuple {
			return ctype{}, vterrors.Errorf(vtrpcpb.Code_INTERNAL, "rhs of an In operation should be a tuple")
		}

		rt, err := rhs.compile(c)
		if err != nil {
			return ctype{}, err
		}

		c.asm.In_slow(c.env.CollationEnv(), expr.Negate)
		return ctype{Type: sqltypes.Int64, Col: collationNumeric, Flag: flagIsBoolean | (nullableFlags(lhs.Flag) | (rt.Flag & flagNullable))}, nil
	default:
		panic("unreachable")
	}
}

func (l *LikeExpr) matchWildcard(left, right []byte, coll collations.ID) bool {
	if l.Match != nil && l.MatchCollation == coll {
		return l.Match.Match(left)
	}
	fullColl := colldata.Lookup(coll)
	wc := fullColl.Wildcard(right, 0, 0, 0)
	return wc.Match(left) == !l.Negate
}

func (l *LikeExpr) eval(env *ExpressionEnv) (eval, error) {
	left, err := l.Left.eval(env)
	if err != nil || left == nil {
		return left, err
	}

View on GitHub (pinned to 01a25a7d17)

Solutions

1. Identify the match kind that hit the default branch
2. Implement a compile case for it (e.g., emitting In_slow or the appropriate matcher)
3. Add early validation in IR translation to reject unknown match kinds with a user-facing error
4. Rebuild so parser IR definitions and compiler are in sync

Example fix

// before		c.asm.In_slow(c.env.CollationEnv(), expr.Negate)
	return ctype{Type: sqltypes.Int64, Col: collationNumeric, Flag: flagIsBoolean | (nullableFlags(lhs.Flag) | (rt.Flag & flagNullable))}, nil
default:
	panic("unreachable")
// after
	case matchKindNew:
		c.asm.NewMatch(c.env.CollationEnv(), expr.Negate)
		return ctype{Type: sqltypes.Int64, Col: collationNumeric, Flag: flagIsBoolean | (nullableFlags(lhs.Flag) | (rt.Flag & flagNullable))}, nil
	default:
		panic("unreachable")

// Confirm the match kind is implemented before compiling
func matchKindSupported(e *evalengine.LikeExpr) bool {
	switch e.MatchKind {
	case evalengine.MatchLike, evalengine.MatchRegexp, evalengine.MatchRegexpIR, evalengine.MatchRegexpSubstr:
		return true
	}
	return false
}

func isSupportedLikeExpr(e evalengine.IR) (*evalengine.LikeExpr, bool) {
	le, ok := e.(*evalengine.LikeExpr)
	return le, ok && matchKindSupported(le)
}

func safeCompileMatch(e *evalengine.LikeExpr, c *compiler) (ct ctype, err error) {
	defer func() {
		if r := recover(); r != nil {
			err = fmt.Errorf("match compile panic: %v", r)
		}
	}()
	return e.compile(c)
}

When it happens

Trigger: Compiling a LikeExpr/match expression whose kind is not one of the handled cases in the compile switch — e.g., a newly introduced match operator or an invalid kind value in a hand-built IR.

Common situations: Adding new pattern-matching operators to the parser/IR without updating the compiler; inconsistent builds; unit tests constructing LikeExpr directly with invalid kinds.

Related errors

• malformed hex literal from parser
• bad unsigned integer type
• bad type aggregation for signed/unsigned types
• unreachable
• unhandled case: evalIsTruthy

AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01). Data as JSON: /api/errors/c4e74f736d6c4b98. Report an issue: GitHub.