Skip to content
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

Ident_env: Assume unknown types are core types #1073

Merged
merged 3 commits into from
Feb 9, 2024

Conversation

Julow
Copy link
Collaborator

@Julow Julow commented Jan 23, 2024

Types that couldn't be found in the environment are looked up in the list of predefined core types.
This lookup is not expected to fail, as indicated by the presence of an assert false.

This removes the core type lookup and assumes all unknown types are core types.

The second commit removes unused Predefined identifiers, paths, references and exceptions. This code required some maintenance in the past.

Julow added 3 commits January 23, 2024 15:22
Types that couldn't be found in the environment are looked up in the
list of predefined core types.
This lookup is not expected to fail, as indicated by the presence of an
`assert false`.

This removes the core type lookup and assumes all unknown types are core
types.
Predefined identifiers, paths, references and exceptions are not used.
Core type are no longer predefined and are instead assumed to be
resolved and constructed on the fly.

This replaces the pre-definition of all the core type with the
`type_of_core_type` function, which construct core types when needed and
only hardcode the representation of known core types.
It doesn't fail.
@Julow Julow added the no changelog This pull request does not need a changelog entry label Jan 23, 2024
@Julow
Copy link
Collaborator Author

Julow commented Jan 23, 2024

The third commit removes the core type lookup in Tools. Instead, core types are constructed on the fly and unknown core types are accepted.
This removes more code from Predefined, which now has a small API.

With this change, Odoc no longer crash when encountering unknown core types (eg. using a patched compiler).

Copy link
Collaborator

@gpetiot gpetiot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, is there a way to add a cram test showing this with a custom core type?

@Julow
Copy link
Collaborator Author

Julow commented Jan 30, 2024

The only way to add custom core types that I know of is to patch the compiler, so no test is possible.

But I believe this is already tested. For example, int is no longer predefined and our tests contains ints.

Copy link
Collaborator

@panglesd panglesd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are so many things in this module that were not used! (core exceptions, paths, references, ...)
Do you have an idea why they were introduced?

In any case (whether my comment in the code is addressed or not) I'm in favor of merging this PR.

Comment on lines +658 to +659
(** Lookup a type in the environment. If it isn't found, it's assumed to be a
core type. *)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That means we are confident there is no error in our building of the environment.
Would it make sense to include a simple check that Ident.name id is part of a list of predefined types? Kind of similar to what was before, but much more lightweight and easily removable.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This patch is intended to be used with patched compilers and not in prevision of new core types. Not having a check is intended.

To more easily debug wrongly built environments, we'd just need to differentiate core types from types that didn't resolve in the generated HTML. We could wrap core types in a span with a class (they don't need to be styled differently for this purpose but could be) but I think we can already debug this case without this.

Copy link
Collaborator

@panglesd panglesd Feb 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that the check is somehow redundant with OCaml having successfully compiled the file, and that it will be annoying for patched compilers.
That might be better than the "easier debugging" of odoc wrongly assigning types to core types.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for reviewing :) Now that we agree, I'll merge!

@Julow Julow merged commit a97ee80 into ocaml:master Feb 9, 2024
10 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no changelog This pull request does not need a changelog entry
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants