Skip to content

fix(conv): check operator type-arguments in applied op-convertibility - #1094

Open
namasikanam wants to merge 1 commit into
mainfrom
fix/conv-drops-type-args
Open

fix(conv): check operator type-arguments in applied op-convertibility#1094
namasikanam wants to merge 1 commit into
mainfrom
fix/conv-drops-type-args

Conversation

@namasikanam

Copy link
Copy Markdown
Collaborator

A soundness bug found by Claude Code. When checking equivalence of two operators, the types of arguments should also be checked. This does not make difference when the operators are not generic, but it does make difference for generic operators.

The `Fapp(Fop(p1,_), _), Fapp(Fop(p2,_), _)` shortcut in `conv`
(ecReduction.ml) treated two applications of the same operator path as
convertible without comparing their type-argument lists. When the type
parameter is "phantom" (present in the operator's definition but reducing
out of its head arrow type), distinct instantiations were wrongly declared
equal.

This is unsound: `reflexivity` proves
  wrap<:bool> 0 = wrap<:unit> 0
for `op wrap ['a] (x:int):int = size (to_seq<:'a> predT)`, while the
stdlib pins those to |bool|=2 and |unit|=1 — yielding a proof of `false`
with no axioms.

The fix mirrors the unapplied `Fop, Fop` case (a few lines above) and
`is_alpha_eq`, both of which already check `List.all2 for_type`. The
change only makes conversion stricter (on a type-arg mismatch it falls
through to the general head-conversion / unfolding path), so it cannot
introduce new conversions; genuinely-true phantom equations still convert
via unfolding.

Adds tests/conv-typeargs.ec, a regression test using `fail reflexivity`:
it compiles once the bug is fixed and fails to compile if it regresses.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@strub
strub force-pushed the fix/conv-drops-type-args branch from 35e2441 to 73f5882 Compare August 21, 2026 13:34
@strub strub self-assigned this Aug 21, 2026
@strub
strub enabled auto-merge August 21, 2026 13:35
@strub
strub disabled auto-merge August 21, 2026 14:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants