stanfordnlp/CoreNLP · error · SemgrexParseException

Use of & in semgrex patterns is now illegal. It is…

Error message

Use of & in semgrex patterns is now illegal.  It is equivalent to the same expression without the &.  Offending expression:

What it means

SemgrexParser no longer permits '&' inside semgrex coordination/negation expressions. Since '&' was equivalent to plain juxtaposition (conjunction within brackets), its use is rejected outright with SemgrexParseException naming the offending token. This enforces the deprecation of ambiguous legacy syntax.

Solutions

  1. Remove the '&' and keep the plain juxtaposed expressions inside the brackets
  2. Split the pattern into simpler sub-patterns or use named edges (e.g. 'zzz > foo > bar')
  3. Rewrite coordinated semantics explicitly, e.g. 'foo < zzz=a : bar < zzz=a'

Example fix

// before
SemgrexPattern p = SemgrexPattern.compile("{} < [foo & bar]");
// after
SemgrexPattern p = SemgrexPattern.compile("{} < [foo bar]");
Defensive patterns

Strategy: validation

Validate before calling

if (pattern.contains("&")) throw new IllegalArgumentException("'&' is illegal in semgrex since 3.6.0; remove it: " + pattern);

Try / catch

try {
  p = SemgrexPattern.compile(pattern);
} catch (SemgrexParseException e) {
  if (e.getMessage().startsWith("Use of &")) { p = SemgrexPattern.compile(pattern.replace("&", " ")); }
  else throw e;
}

Prevention

When it happens

Trigger: Parsing a semgrex pattern containing '&' as a conjunction operator between node expressions, e.g. '{tag:NN} < [foo & bar]', or legacy patterns with '&' carried over from older CoreNLP.

Common situations: Running old semgrex strings from published papers or scripts against a newer CoreNLP; hand-writing patterns that mimic tregex syntax.

Understand the failure class

Background: "is deprecated and will be removed" — deprecation warnings for old API names, keywords, and options, and how to migrate before the removal release — this error's family across 29 libraries.

Related errors

AI-assisted analysis of stanfordnlp/CoreNLP@1b7edd19c4 (2026-09-10). Data as JSON: /api/errors/8b492acb3cba8520. Report an issue: GitHub.

Appendix: source

Thrown at src/edu/stanford/nlp/semgraph/semgrex/SemgrexParser.jj:106

  // a local variable
} {
  {
    // start from 1 since we haven't parsed anything yet
    startToken = getToken(1);
  }
  (
    (
      (reverse = <ALIGNRELN> node = SubNode(GraphRelation.ALIGNED_ROOT))
      |
      ( node = SubNode(GraphRelation.ROOT) { children.add(node); }
        ( ":" node = SubNode(GraphRelation.ITERATOR) { children.add(node); } )*
      )
    )
    {
      if (children.size() > 1)
        node = new CoordinationPattern(true, children, true, true);
      if (deprecatedAmp) {
        throw new SemgrexParseException("Use of & in semgrex patterns is now illegal.  It is equivalent to the same expression without the &.  Offending expression: " + startToken);
      }
      if (deprecatedNodeConj) {
        throw new SemgrexParseException("Use of node conjugation (expressions such as '< [foo bar]' or '< [foo & bar]') is now illegal.  The issue is that expressions such as '[foo bar] < zzz' may intuitively mean that foo < zzz, bar < zzz, zzz the same for both cases, but that is not the way the parser interpreted this expression.  Changing the functionality might break existing expressions, and anyway this can be rewritten in various ways such as 'zzz > foo > bar' or 'foo < zzz=a : bar < zzz=a'.  Offending expression: " + startToken);
      }
    }
  )
  (
    (
      "::" <UNIQ> { uniqKeys = new ArrayList<>(); }  (nextIdentifier = identifier() { uniqKeys.add(nextIdentifier.image); })*
      {
        for (String key : uniqKeys) {
          if (!knownVariables.contains(key)) {
            throw new SemgrexParseException("Semgrex pattern asked for uniq of node " + key + " which does not exist in the pattern");
          }
        }
        // TODO: can error check that the keys are unique between node and edge names
        // that might require keeping edge names in a known set
        // TODO: edge names might need some upgrades anyway - shouldn't name them under negation, for example

View on GitHub (pinned to 1b7edd19c4)