Skip to content

Do not normalize erased spec arguments during extraction - #4830

Open
gebner wants to merge 1 commit into
masterfrom
gebner_specargnorm
Open

gebner wants to merge 1 commit into
masterfrom
gebner_specargnorm

Conversation

@gebner

@gebner gebner commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

Fixes #4828.

Under ForExtraction, when the normalizer rebuilds an application whose head is a stuck fvar, arguments in computationally irrelevant binder positions are now replaced instead of being normalized:

  • prop binders (and Tot/GTot arrows into prop, when closed) → l_True
  • other non-informative binders (slprop, erased, squash, erasable types, ...) → ()
  • arities (Type, a -> Type, ...), unit (thunks), and primitive-step heads (e.g. reveal/hide) are left alone

Per-fvar results are cached, validated against the current sigelt by physical equality.

On the MWE from the issue (N=20 prop chain), extraction goes from Error 365 after ~10s to 0.09s with identical output.

Tests:

  • tests/custard/SpecArgNorm.fst (N=12, --custard_norm_budget 20000; fails on master)
  • tests/custard/pulse/PulseSpecArgNorm.fst (N=14 slprop and prop chains, budget 1e5); the pulse Makefile's %.custard.ml rule now passes FLAGS_$*.

Also adds a note to doc/ref/custard.md.

Under ForExtraction, arguments of stuck fvar-headed applications in
computationally irrelevant binder positions (prop, prop-valued arrows,
non-informative types like slprop/erased/squash) are replaced by
l_True / () instead of being normalized. This avoids blowups (and
Error 365 from --custard_norm_budget) on large spec-only arguments.

Fixes #4828

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

This branch has not been deployed

No deployments
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.

Custard: normalizing erased implicit arguments makes extraction slow (Error 365)

1 participant