In the following example, the expr syntax category has two rules, which create an ambiguity: an ident can be directly an expression, or a nullary application. Ideally, this should trigger a warning or an error, but it doesn't, and, although just by looking at the source code, it looks like all the cases of the parse tree are handled, the expression f x reaches the catchall case.
import Lean
open Lean Meta Elab
open Lean.Elab.Command (liftTermElabM)
declare_syntax_cat expr
syntax "#demo " expr : command
syntax:60 ident expr:61* : expr
syntax:90 ident : expr
partial def elab_expr : Lean.TSyntax `expr → CoreM Unit
| `(expr| $_:ident) => return ()
| `(expr| $_:ident $args:expr*) => do
for arg in args do
elab_expr arg
| s => throwErrorAt s m!"{repr s}"
elab_rules : command
| `(command| #demo $expr) => liftTermElabM <| elab_expr expr
#demo f x
Context
See the zulip thread where this issue was first reported.
Versions
Tested on Lean 4.12.0 on a NixOS/nixpkgs unstable computer, and on Lean nightly on live.lean-lang.org.
Prerequisites
Please put an X between the brackets as you perform the following steps:
Description
In the following example, the
expr
syntax category has two rules, which create an ambiguity: anident
can be directly an expression, or a nullary application. Ideally, this should trigger a warning or an error, but it doesn't, and, although just by looking at the source code, it looks like all the cases of the parse tree are handled, the expressionf x
reaches the catchall case.Context
See the zulip thread where this issue was first reported.
Versions
Tested on Lean 4.12.0 on a NixOS/nixpkgs unstable computer, and on Lean nightly on live.lean-lang.org.
Impact
Add :+1: to issues you consider important. If others are impacted by this issue, please ask them to add :+1: to it.