-
Notifications
You must be signed in to change notification settings - Fork 99
Alias more when strengthening #653
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
Alias more when strengthening #653
Conversation
This patch reduces the produced HTML in accessor_core from 1.8 megs to 570k |
02220e9
to
d030c77
Compare
This needs some extra work - it's leading to broken links. For example, the first line in |
4e6a198
to
e5e7b23
Compare
Not just the ones that weren't already aliases
The logic behind stripping the Alias was that in the vast majority of cases, the canonical path points to a module that's the alias of the actual hidden module. This isn't always a valid assumption - for example in `base.caml`, which creates canonical aliases to stdlib.
The previous version would resolve the canonical path, then try to move as much of it into the identifier as possible. For example, if a module in, say, `Base.String` was referencing a type `t` in `Base.Buffer`, it would resolve `Base.Buffer.t` (the canonical path), then see if `Buffer.t` was the same thing, then check just `t`, where in these cases, `Base`, then `Buffer`, then `t` are fully qualified but not fully rendered identifiers. Unfortunately if the canonical path was not expanded we'd end up with the wrong path rendered. For example, `Caml.Buffer` is an alias to `Stdlib.Buffer`, but it is marked as canonical. We would then end up with `Stdlib.Buffer` where we would have liked `Caml.Buffer` or even just `Buffer` to have appeared.
e5e7b23
to
f19caea
Compare
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.
I'm not familiar with the strengthen logic but this sounds good to me.
src/xref2/strengthen.ml
Outdated
| None -> (item :: items, s) | ||
| Some m' -> (Module (id, r, put (fun () -> m')) :: items, id :: s)) | ||
let m' = module_ ?canonical (`Dot (prefix, name)) (get m) in | ||
(Module (id, r, put (fun () -> m')) :: items, id :: s) |
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.
The whole computation of m'
could be delayed (it's not used otherwise)
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.
Good spot!
(fun s mid -> Subst.path_invalidate_module (mid :> Ident.path_module) s) | ||
Subst.identity strengthened_modules | ||
in | ||
Subst.signature substs sg' |
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.
We can apply this only if strengthened_modules
is not empty.
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.
I couldn't measure a performance improvement (it is smaller than the noise).
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.
I'm slightly hesitant to do this because it would mean the identifiers don't get fresh names even though they're changed.
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.
I haven't thought the identity subst would still have an effect. It makes sense here.
No description provided.