rust-lang/rust-analyzer · error · SsrError

Unsupported constraint type '{}'

Error message

Unsupported constraint type '{}'

What it means

SSR currently supports only two constraint types: kind(...) and not(...). parse_constraint matches the constraint name against these; anything else (after lexing as an ident) triggers this error naming the unsupported constraint. Note that constraints can also be separated by ',' inside a placeholder, each parsed recursively.

Source

Thrown at crates/ide-ssr/src/parsing.rs:329

    match constraint_type.as_str() {
        "kind" => {
            expect_token(tokens, "(")?;
            let t = tokens.next().ok_or_else(|| {
                SsrError::new("Unexpected end of constraint while looking for kind")
            })?;
            if t.kind != SyntaxKind::IDENT {
                bail!("Expected ident, found {:?} while parsing kind constraint", t.kind);
            }
            expect_token(tokens, ")")?;
            Ok(Constraint::Kind(NodeKind::from(&t.text)?))
        }
        "not" => {
            expect_token(tokens, "(")?;
            let sub = parse_constraint(tokens)?;
            expect_token(tokens, ")")?;
            Ok(Constraint::Not(Box::new(sub)))
        }
        x => bail!("Unsupported constraint type '{}'", x),
    }
}

fn expect_token(tokens: &mut std::vec::IntoIter<Token>, expected: &str) -> Result<(), SsrError> {
    if let Some(t) = tokens.next() {
        if t.text == expected {
            return Ok(());
        }
        bail!("Expected {} found {}", expected, t.text);
    }
    bail!("Expected {} found end of stream", expected);
}

impl NodeKind {
    fn from(name: &SmolStr) -> Result<NodeKind, SsrError> {
        Ok(match name.as_str() {
            "literal" => NodeKind::Literal,
            _ => bail!("Unknown node kind '{}'", name),

View on GitHub (pinned to e8f7e90aa3)

Solutions

1. Use only kind(...) or not(...) constraints
2. Express the desired restriction differently, e.g. not(kind(literal)) for negative kinds
3. Check spelling and case: constraint names are lowercase 'kind' and 'not'

Example fix

// before
let pattern = "$x:has_type(u32)";
// after
let pattern = "$x:kind(literal)"; // or nest: not(kind(literal))

const ALLOWED_CONSTRAINTS: &[&str] = &["kind", "not"];
fn has_supported_constraints(p: &str) -> bool {
    // extract identifier before each '(' that follows ':' or ',' inside a placeholder
    p.split(|c: char| c == '$' || c == '{' || c == '}')
        .flat_map(|seg| seg.split(':'))
        .filter_map(|c| c.split_once('('))
        .all(|(name, _)| ALLOWED_CONSTRAINTS.contains(&name.trim()))
}

match parse_pattern(pattern) {
    Ok(p) => use_pattern(p),
    Err(e) if e.message.contains("Unsupported constraint type") => {
        eprintln!("Only kind(...) and not(...) constraints are supported");
    }
    Err(e) => return Err(e),
}

When it happens

Trigger: Writing ${name:has_type(...)}, ${name:parent(...)} or any constraint keyword other than kind/not in a pattern placeholder.

Common situations: Assuming SSR supports type or trait constraints like IDE 'live template' constraints; porting patterns from other structural-search tools (e.g. Semgrep/Comby) that have richer constraint vocabularies; typos like kindz or Kind.

Related errors

• Expected ident, found {:?} while parsing kind constraint
• Expected {} found {}
• Expected {} found end of stream
• Unknown node kind '{}'
• Failed to parse pattern: {}

AI-assisted analysis of rust-lang/rust-analyzer@e8f7e90aa3 (2026-09-03). Data as JSON: /api/errors/83cdcffeece241e1. Report an issue: GitHub.