-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix the type_expr loader in OCaml 4.14 and later #1173
Conversation
Physical equality should not be used on type_expr to detect equality of type variable node, since we are only interested by equality up to equivalence in the union-find structure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I've added a test case in Octachron#1 if you agree with it.
I think this deserves a change entry.
I have merged the test and added a changes entry, thanks ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks !
CHANGES: ### Fixed - Fix missing katex headers (@panglesd, ocaml/odoc#1096) - Allow `][` in code blocks, fixing issue ocaml/odoc#1137 (@Julow, ocaml/odoc#1149) This was interpreted as "code blocks with result", which now mandates a delimiter: `{delim@lang[ code ]delim[ result ]}` - Fix misprinting of type variables from ml files for OCaml 4.14 and later (multiple occurences of the same type variable could be named differently) (@Octachron, ocaml/odoc#1173)
Currently, generating documentation from ml files
makes odoc misprint equal type variables as distinc type variables:
starting from OCaml 4.14 .
This issue stems from the uses of physical equalities on non-representative type expressions in the name map of the type expression loader of odoc. Consequently, different type nodes are attributed different names by odoc, even if they belong to the same class of equal-after-unification type nodes.
This issue typically doesn't arise when using mli files, because then we read source type expressions directly, without doing any unification (in most cases?).
This PR fixes this issue by ensuring that the naming maps only use representative type expressions.
Fortunately, this requires mostly tweaks to the
Compat
module.