Skip to content

Fix canonical #820

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

Merged
merged 3 commits into from
Feb 5, 2022
Merged

Fix canonical #820

merged 3 commits into from
Feb 5, 2022

Conversation

jonludlam
Copy link
Member

Fixes #724.

I'd still like to verify that paths containing canonical modules are correct, but we weren't doing that before, either. See the new test for an example of this not working.

Given a fully qualified canonical path: `X.Y.Z`, we now resolve
`X.Y.Z` and check it works. If it does, we then resolve `Y.Z`
and `Z`, and pick the shortest one for which the identifier
is the same as the fully qualified path.

Additionally, we now also expand modules that are 'self canonical'
even if the module they're an alias of is not hidden. This has
led to the new expansion of Ocamlary.Aliases.P2.Z in the generator
tests.
}
}

This should probably not resolve at all, but that's a problem for another day. currently it resolves as Test.Wrapper3.X
Copy link
Collaborator

Choose a reason for hiding this comment

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

There should be a warning at location of the canonical tag.

Copy link
Member Author

Choose a reason for hiding this comment

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

A warning should be emitted, yes. I think we should address this in a separate PR though.

Comment on lines 64 to 66
and [possibilities] is a function that, given the fully qualified
unresolved path, returns a list of all possible unresolved paths
(including the longest one) *)
Copy link
Collaborator

Choose a reason for hiding this comment

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

possibilities should be sorted, shortest first ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, I'll mention that.

Comment on lines +86 to +88
let resolved = filter_map resolve (possibilities env p2) in
let find_fn (r, _) = get_identifier r = fallback_id in
try Some (List.find find_fn resolved) with _ -> None)
Copy link
Collaborator

Choose a reason for hiding this comment

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

filter_map can be avoided by doing resolve and find_fn directly during the List.find.

Copy link
Member Author

Choose a reason for hiding this comment

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

But then I'd have to call resolve again. I could write a bit more of a specialised function but I opted for legibility here.

Comment on lines +1090 to +1092
If a module doesn't know it's canonical, it will fail the self-canonical check, and
therefore not necessarily be expanded. If this happens, we call [process_module_path]
to stick the [`Alias] constructor back on so we'll link to the correct place. *)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Shouldn't this be done by the caller ? Because like this, it'll still be wrapped in a `Canonical and that makes this function part of the complicated recursive functions.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'd prefer to leave it here so we don't spread the logic between two functions. It'd be better if we have one function to test for self-canonical modules that we can call from here and also from link.ml, but there's a bit of refactoring required for that.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I mean the resolving could fail and the function that handles the `Canonical case can start again by calling reresolve_module and at the same time removing the `Canonical constructor.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, no, the canonical is still valid, it's just that it's going to point to the aliased module rather than the module itself, as the module itself won't be expanded because it doesn't know it's canonical :-)

Copy link
Collaborator

Choose a reason for hiding this comment

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

I see.

@jonludlam jonludlam merged commit bbc00f9 into ocaml:master Feb 5, 2022
jonludlam added a commit to jonludlam/opam-repository that referenced this pull request Feb 8, 2022
CHANGES:

Additions
- New subcommand to resolve references (@panglesd, @lubega-simon, ocaml/odoc#812)
- Improved rendering of long signatures (@panglesd, ocaml/odoc#782)
- Handle comments attached to open statement as floating comment, instead
  of dropping them (@panglesd, ocaml/odoc#797)
- Empty includes (containing entirely shadowed entries) are now hidden (@panglesd, ocaml/odoc#798)

Bugs fixed
- Fix a missing Result constructor during compile. This will cause some
  functor arguments to have different filenames (@jonludlam, ocaml/odoc#795)
- Better memory/disk space usage when handling module alias chains (@jonludlam, ocaml/odoc#799)
- Resolving class-type paths (ie., `val x : #c`) (@jonludlam, ocaml/odoc#809)
- Skip top-level attributes while extracting the top comment. Fix top-comment extraction with PPX preprocessing (@jorisgio, ocaml/odoc#819)
- Better handling of @canonical tags (@jonludlam, ocaml/odoc#820)
- css: improved layout (@jonludlam, @Julow, ocaml/odoc#822)
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.

Issues with @canonical
2 participants