Why this fires¶
A known enum was identified for this site — either as the base of EnumName::variant (or the equivalent pattern forms, EnumName::variant(...) / EnumName::variant { ... }), or as the type of a match/let scrutinee matched against an inferred-enum shorthand pattern (.variant) — but the variant name doesn't match any of that enum's declared variants. This is almost always a typo (a "did you mean?" suggestion is attached when a close match exists).
enum Color { Red, Green, Blue }
fn f() {
let c = Color::Rd
// ^^ error[TE133]: enum 'Color' has no variant 'Rd'. Did you mean 'Red'?
}The same check applies to enum patterns in match arms and let/parameter destructuring, for both tuple-shaped and struct-shaped variants:
enum Shape { Circle(int), Square(int) }
fn area(s: Shape) -> int {
match s {
Shape::Circl(r) => r,
// ^^^^^^ error[TE133]: enum 'Shape' has no variant 'Circl'. Did you mean 'Circle'?
_ => 0,
}
}The inferred-enum shorthand form of a pattern reports through this same code — the enum comes from the scrutinee's type instead of from a written path, but the mistake and the message are identical:
enum Shape { Circle(int), Square(int) }
fn area(s: Shape) -> int {
match s {
.Circl(r) => r,
//^^^^^^^ error[TE133]: enum 'Shape' has no variant 'Circl'. Did you mean 'Circle'?
_ => 0,
}
}The shorthand in expression position is the one case that does not use this code: it reports TE137 instead, so that the two shorthand failure modes (enum not inferable vs. variant not found) sit next to each other.
TE133 only fires when both of these hold:
- An enum is identified for the site: the base name resolves to a genuine
Type::Enum(a real, declared enum — including generic ones likeOption<T>/Result<T, E>, and through anOptional<Enum>narrowed binding), or, for a shorthand pattern, the scrutinee's type does. - The variant name isn't found among that enum's declared variants, and — at the expression-path site — it also isn't a real method on that type (
Type::methodstatic/impl-method references take priority over a variant-typo diagnosis, since a method can legally share a name with what would otherwise look like a variant).
It deliberately stays silent — matching the prior, permissive behavior — when:
- The base name doesn't resolve to any known type at all (an unrelated diagnostic, or nothing, covers that case; guessing variants for an unknown type isn't possible). For a shorthand pattern, this is the un-inferable-scrutinee case —
match some_untyped_value { .Ok(v) => … }stays permissive, exactly asmatch some_untyped_value { Result::Ok(v) => … }always has. - The base resolves to a type that isn't an enum (struct, primitive, type parameter, etc.).
- The name is found but names a variant of a different kind than the pattern expects (e.g. matching a tuple pattern against a struct-shaped variant) — that's a shape mismatch, not an unknown-variant typo, and is out of scope for this code.
Fix it¶
1. Fix the spelling¶
Trust the "did you mean?" suggestion when it appears — it's computed against the enum's real declared variant names.
enum Color { Red, Green, Blue }
let c = Color::Red // fixed2. Check you're matching against the right enum¶
If the suggestion looks unrelated, the pattern or path may be naming the wrong enum entirely (two enums with similarly-named variants). Confirm the scrutinee's/base's declared type — with a shorthand pattern that declared type is the only thing choosing the enum, so it is worth writing the qualified form once to see which enum the compiler picked.
3. Declare the variant if it's genuinely new¶
If the "typo" is actually a variant you meant to add, add it to the enum declaration:
enum Color { Red, Green, Blue, Rd } // if `Rd` was intentional, name it explicitlySee also¶
TE123— the equivalent "did you mean?" check for unknown struct fields in patterns.TE137— the same failure for a.Variantshorthand in expression position.TE136— a.Variantshorthand whose enum could not be inferred at all.- /docs/data-structures#enums — enum declarations, unit/tuple/struct variants, and pattern matching.