Add elaboration of qualities #21450

TDiazT · 2025-12-22T19:07:54Z

This PR depends on #21417 .

This PR adds elaboration of (implicit) qualities, which is enabled by setting the flag Universe Polymorphism and disabling a new flag Collapse Sorts ToType.

Associated RFC : rocq-prover/rfcs#111.

Examples

The test file test-suite/success/sort_poly_elab.v has been updated with more examples.

Set Universe Polymorphism.
Unset Collapse Sorts ToType.

Definition qsort := Type.
(* qsort@{α ; u |} = Type@{α ; u} : Univ@{u+1} *)

Definition qsort' := Type.
(* qsort'@{u} : Type@{u+1} *)

Inductive implicit := mk.
(* implicit@{α ; u} : Type@{α ; u} *)

Inductive foo1 : Type := .
(* foo1@{α ; u |} : Type@{α ; _} :=  . *)

Inductive sigma (A:Type) (B:A -> Type) : Type
    := pair : forall x : A, B x -> sigma A B.
  (* sigma@{α α0 α1 ; u u0 u1} : forall (A : Type@{α ; u}) (_ : forall _ : A, Type@{α0 ; u0}), Type@{α1 ; u1} *)

(* Elimination constraints are added *)
Definition pr1 {A B} (s:sigma A B) : A
  := match s with pair _ _ x _ => x end.
(* α α0 α1 ; u u0 u1 |= α1 -> α *)

Definition pr2 {A B} (s:sigma A B) : B (pr1 s)
  := match s with pair _ _ _ y => y end.
(* α α0 α1 ; u u0 u1 |= α1 -> α
                                    α1 -> α0 *)

Overlays

Adapt to rocq-prover/rocq#21450 (Update esearch_fix_guard to return evd) mattam82/Coq-Equations#688

Added / updated test-suite.
Added changelog.
Added / updated documentation.
- Documented any new / changed user messages.
Opened overlay pull requests.

tabareau · 2026-01-06T16:56:38Z

@coqbot run full ci

TDiazT · 2026-01-27T13:48:19Z

I found a bug when declaring a variable in Type in a section, so I still need to check that.

Set Universe Polymorphism.
Unset Collapse Sorts ToType.

Section Test.
  Variable (A : Type).
  (* Anomaly "File "kernel/safe_typing.ml", line 698, characters 11-17: Assertion failed." Please report at http://rocq-prover.org/bugs/. *)

Which comes from this check:

  let check_quality q =
    Sorts.QVar.is_global q &&
    not (QGraph.is_declared (Sorts.Quality.QVar q) (Environ.qualities senv.env))
  in
  let () = assert (Sorts.QVar.Set.for_all check_quality (fst qctx)) in

Apart from that, I think the projections are now currently elaborated with their appropriate elimination constraints, not just collecting.

SkySkimmer · 2026-01-27T14:30:11Z

Currently we expect that all qvars in the global env (including section qualities) are QVar.is_global, this check enforces that.
The alternatives are Unif and debruijn variables so neither really seem to fit in the section context. (debruijn variables wouldn't work with instantiating pomymorphic objects I think)

TDiazT · 2026-01-27T16:29:18Z

@ppedrot Why should sort variables be only global inside a section? According to the assertion:

  let check_quality q =
    Sorts.QVar.is_global q &&
    not (QGraph.is_declared (Sorts.Quality.QVar q) (Environ.qualities senv.env))
  in
  let () = assert (Sorts.QVar.Set.for_all check_quality (fst qctx)) in

What cases is this assertion protecting from?

SkySkimmer · 2026-01-28T16:07:17Z

vernac/declare.ml

+  (* We need sigma to check for elimination constraints. In most cases it's None, except for
+     [declare_mutual_definitions] where we get it from UState. *)
+  let sigma = Option.default (Evd.from_env env) sigma in
+  let _, indexes = Pretyping.search_guard env sigma possible_guard rec_declaration in


The change in the output for FixpointNoElim is because in master this search_guard fails, and in this PR we ignore the returned evar map (which would have an added s -> Prop) and then the kernel fails.

I'm not sure to what extent this is a problem, but it doesn't seem great.

output change is still there as of d04f191 AFAICT

vernac/attributes.ml

vernac/record.ml

SkySkimmer · 2026-01-28T16:17:54Z

test-suite/success/sort_poly_elab.v

-Arguments inl {A B} _ , [A] B _.
-Arguments inr {A B} _ , A [B] _.
+  Definition qsort := Type.
+  (* qsort@{α ; u |} = Type@{α ; u} : Type@{u+1} *)


instead of comments which are not checked by anything, this should be an output test (with an added About instead of the comment)

alternatively we could write some code to check that the expected thing is produced but it would get verbose, eg to check that an expected definition foo@{s s'; | s -> s'} we have to do

Fail Definition foo_check@{s s';|} := foo@{s s';}. (* missing elim constraint *) Definition foo_check@{s s';|s -> s'} := foo@{s s';}.

and if there is more than 1 elim constraint fully checking it gets exponential (we have to check that every strict subset of the constraints is rejected)

Yup, those were more for documentation, if someone looks at the test without needing to run them. I'll add the output tests.

I'd prefer for the whole test to be moved to output and every comment be accompanied by a About

engine/polyFlags.mli

SkySkimmer · 2026-01-28T16:19:31Z

engine/evd.mli


 (** Universe minimization (collapse_sort_variables is true by default) *)
-val minimize_universes : ?collapse_sort_variables:bool -> evar_map -> evar_map
+val minimize_universes : ?collapse_sort_variables:bool -> ?to_type:bool -> evar_map -> evar_map


this API seems a bit awkward (to_type is ignored when collapse = false) but IDK what would be better

Yeah, I agree. The only use I've seen for collapse is for template I think.

SkySkimmer · 2026-01-28T16:22:46Z

kernel/inductive.mli

-val check_fix : ?evars:evar_handler -> ?elim_to:(Sorts.Quality.t -> Sorts.Quality.t -> bool) -> env -> fixpoint -> unit
+val check_fix_pre_sorts : ?evars:evar_handler -> env -> fixpoint -> (Sorts.t * Sorts.t) option array
+(** Checks fixpoint without checking sort elimination constraints.
+   Returns an array of possible sorts (None if Type in Type) *)


not sure what "possible sorts" means, is it "for each fixpoint the pair of structural argument's sort and output's sort"?
also since type in type isn't per-fixpoint it should be _ array option not _ option array

I'll edit it, don't actually remember.

SkySkimmer · 2026-01-28T16:26:32Z

@ppedrot Why should sort variables be only global inside a section? According to the assertion:
  let check_quality q =
    Sorts.QVar.is_global q &&
    not (QGraph.is_declared (Sorts.Quality.QVar q) (Environ.qualities senv.env))
  in
  let () = assert (Sorts.QVar.Set.for_all check_quality (fst qctx)) in
What cases is this assertion protecting from?

It stops us from putting Var qvars in the section context (this would either produce errors or cause inconsistencies), and also Unif qvars (they would probably work ok but it's strange to have "unification" variables in the section context).

changed

TDiazT · 2026-01-29T09:55:18Z

It stops us from putting Var qvars in the section context (this would either produce errors or cause inconsistencies), and also Unif qvars (they would probably work ok but it's strange to have "unification" variables in the section context).

How is it handled for universe levels ? Can we use the same approach?

SkySkimmer · 2026-01-29T10:04:14Z

For univ levels unif and global are the same
This is generally considered not great
@ppedrot ?

ppedrot · 2026-01-29T10:42:44Z

How is it handled for universe levels ? Can we use the same approach?

No, we shouldn't reflect the level implementation for sorts, and this is a hill I will die on. Monomorphic sorts are like constants, not unification variables.

For sections I'm open to discussion, but I'm still quite convinced that allowing unification of section-local sorts is a bad idea. It's less crazy than unification of global sorts since there is an explicit scope, but still. As for the precise way to implement it, I don't know whether we should use QVars or globals, but this is mostly an implementation detail, both are observationally equivalent except maybe for some printing functions.

TDiazT · 2026-02-03T09:56:05Z

Monomorphic sorts are like constants, not unification variables.

Sounds fair.

For sections I'm open to discussion, but I'm still quite convinced that allowing unification of section-local sorts is a bad idea. It's less crazy than unification of global sorts since there is an explicit scope, but still. As for the precise way to implement it, I don't know whether we should use QVars or globals, but this is mostly an implementation detail, both are observationally equivalent except maybe for some printing functions.

I'm unfamiliar with how exactly the section context works wrt. to definitions in the section, so in order to clarify a little bit:

With the local assumption Variable (A : Type) I would get a fresh Unif sort variable for Type. Then, what exactly is it that you are suggesting?

That we should elaborate this sort variable as a Var/Global one, instead of a Unif, when inside a section?
I imagine not, since there shouldn't be section-specific logic in the elaboration/pretyping phase.
that we should somehow store this unif variable in the section context as a QVar or Global one?
In this case, I imagine there might be issues when typing other terms, since the sort variable for A is different than the one in the context. Unless you keep some kind of mapping between them?
Otherwise, maybe substitute these Unif variables for the QVar ones that are now stored in the context? (This doesn't sound good to me)
I'm lost here because I don't really know the ramifications of this idea of having QVars instead of the Unifs that were generated.
Something else entirely?

For sections I'm open to discussion, but I'm still quite convinced that allowing unification of section-local sorts is a bad idea.

Why do you think it's bad ?

SkySkimmer · 2026-02-05T14:17:07Z

Maybe we could have version of the PR where section variables do not support elaborating qualities (error not yet implemented if there are non empty implicit qualities / elim constraints to add to the section context), then I think it would be mergeable and we can think about sections separately.

TDiazT · 2026-02-06T09:41:46Z

Maybe we could have version of the PR where section variables do not support elaborating qualities (error not yet implemented if there are non empty implicit qualities / elim constraints to add to the section context), then I think it would be mergeable and we can think about sections separately.

Sounds good, I'll adjust it then (plus check that evar map that we are ignoring after checking the guard).

SkySkimmer · 2026-02-09T15:59:26Z

vernac/record.ml

+    match Constr.kind c with
+    | Const (c, _) -> (
+        let label = Constant.label c in
+        match Id.Map.find_opt label elim_cstrs_map with


looking by label seems very wrong, if we use some constant from another module with the same name as a projection it will be treated as the projection

Can you give an example? How does the system disambiguate in that case?

If we have something like:

Record R : Type := { Rf1 : Type ; Rf2 : Rf1 }.

How could the type of Rf2, ie. Rf1, refer to another constant from another module ? Wouldn't there be a check to disambiguate, failing or requiring some namespace prefix, e.g. M.Rf1.

When adding the constraints for Rf2 we would have the mapping (Rf1 -> (α ~> Type)) from the previous field, not M.Rf1. So I don't see how having Rf2 : M.Rf1 could include unnecessary constraints from the first field. Unless the prefix M. is not part of the label?

Unless the prefix M. is not part of the label?

yes

in

Module M. Definition Rf1 := nat. End M. Record R : Type := { Rf1 : Type ; Rf2 : M.Rf1 }.

the label of M.Rf1 is "Rf1"

in general values in the type Id.t do not contain . characters

coqbot-app bot added the needs: full CI The latest GitLab pipeline that ran was a light CI. Say "@coqbot run full ci" to get a full CI. label Dec 22, 2025

TDiazT force-pushed the elab-sorts branch 3 times, most recently from cda08c0 to 26bf881 Compare December 24, 2025 13:19

github-actions bot added the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Dec 31, 2025

TDiazT force-pushed the elab-sorts branch from 26bf881 to ad55557 Compare January 6, 2026 14:53

coqbot-app bot removed the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Jan 6, 2026

coqbot-app bot removed the needs: full CI The latest GitLab pipeline that ran was a light CI. Say "@coqbot run full ci" to get a full CI. label Jan 6, 2026

TDiazT added a commit to TDiazT/rocq-lean-import that referenced this pull request Jan 7, 2026

Adapt to rocq-prover/rocq#21450 (Add poly flag to declare_projections)

e4d5676

TDiazT added a commit to TDiazT/Coq-Equations that referenced this pull request Jan 7, 2026

Adapt to rocq-prover/rocq#21450 (Update esearch_fix_guard to return evd)

a70592f

TDiazT added a commit to TDiazT/Coq-HoTT that referenced this pull request Jan 7, 2026

Adapt to rocq-prover/rocq#21450 (Section Univ -> Section Universe)

8d13271

TDiazT added a commit to TDiazT/coq-elpi that referenced this pull request Jan 7, 2026

Adapt to rocq-prover/rocq#21450 (Add poly flags to declare_projections)

a2000cf

github-actions bot added the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Jan 8, 2026

TDiazT force-pushed the elab-sorts branch from c138298 to 67189c9 Compare January 15, 2026 23:30

coqbot-app bot added needs: full CI The latest GitLab pipeline that ran was a light CI. Say "@coqbot run full ci" to get a full CI. and removed needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. labels Jan 15, 2026

github-actions bot added the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Jan 16, 2026

TDiazT force-pushed the elab-sorts branch from 67189c9 to 9eed7dc Compare January 17, 2026 17:58

coqbot-app bot removed the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Jan 17, 2026

TDiazT force-pushed the elab-sorts branch 2 times, most recently from 4cfacbd to 3f8c2f6 Compare January 19, 2026 10:40

TDiazT marked this pull request as ready for review January 19, 2026 10:41

TDiazT requested review from a team as code owners January 19, 2026 10:41

feat: Add more specific elim constraints to non-prim projections

b1f28f3

TDiazT force-pushed the elab-sorts branch from 442275a to b1f28f3 Compare January 27, 2026 13:50

SkySkimmer reviewed Jan 28, 2026

View reviewed changes

vernac/attributes.ml Outdated Show resolved Hide resolved

SkySkimmer reviewed Jan 28, 2026

View reviewed changes

vernac/record.ml Outdated Show resolved Hide resolved

SkySkimmer reviewed Jan 28, 2026

View reviewed changes

engine/polyFlags.mli Outdated Show resolved Hide resolved

SkySkimmer reviewed Jan 28, 2026

View reviewed changes

SkySkimmer added this to the 9.3+rc1 milestone Jan 28, 2026

TDiazT added 2 commits January 29, 2026 13:11

Address comments

10a5427

refactor: Pass on sigma in search_guard

fdf4b62

test: Move sort_poly_elab test to output folder

cbda044

TDiazT added 2 commits February 9, 2026 10:33

fix: Change assert implicit sort vars for error in sections

878074c

fix(attempt): Return evd from make_recursive_bodies

d04f191

SkySkimmer reviewed Feb 9, 2026

View reviewed changes

TDiazT force-pushed the elab-sorts branch from c727292 to c1101c4 Compare February 10, 2026 10:31

refactor: Change option array to list option

cc003ef

TDiazT force-pushed the elab-sorts branch from c1101c4 to cc003ef Compare February 10, 2026 10:36

Add elaboration of qualities #21450

Are you sure you want to change the base?

Add elaboration of qualities #21450

Uh oh!

Conversation

TDiazT commented Dec 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Examples

Overlays

Uh oh!

tabareau commented Jan 6, 2026

Uh oh!

TDiazT commented Jan 27, 2026

Uh oh!

SkySkimmer commented Jan 27, 2026

Uh oh!

TDiazT commented Jan 27, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SkySkimmer commented Jan 28, 2026

Uh oh!

TDiazT commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SkySkimmer commented Jan 29, 2026

Uh oh!

ppedrot commented Jan 29, 2026

Uh oh!

TDiazT commented Feb 3, 2026

Uh oh!

SkySkimmer commented Feb 5, 2026

Uh oh!

TDiazT commented Feb 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

TDiazT commented Dec 22, 2025 •

edited

Loading

TDiazT commented Jan 29, 2026 •

edited

Loading