-
-
Notifications
You must be signed in to change notification settings - Fork 671
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
Hxb #11266
Hxb #11266
Conversation
let rec get_reader ctx input mpath p = | ||
let make_module path file = | ||
let m = ModuleLevel.make_module ctx path file p in | ||
m.m_extra.m_processed <- 1; |
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.
Is this necessary? With the initial compilation_step = 1
it seems fine to leave this at 0.
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.
is_cached
explicitly checks for m.m_processed <> 0
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.
Yes but is that necessary if the compilation step starts at 1 anyway?
39be59a
to
5c2162f
Compare
I have added some support for local type parameters but I don't know if this is a good approach. Due to the leaky nature of these things it might be better to just enumerate all local type parameters across an entire field and use their identity for indexing. That's not very elegant but should be quite robust and easy to implement. |
This reverts commit 71678b2.
We will open a new PR from a different branch soon! |
Continued in #11504
Random TODOs:
¹
module_resolution
branch)¹
Current type parameter issues:[unit.TestGADT] Unbound type parameter EBinop.C
which can be fixed by commenting out line 282 ofsrc/typing/matcher/exprToPattern.ml
(TODO check if doing this is fine)[unit.TestMatch] Unbound type parameter ref.T
and[unit.issues.Issue2889] Unbound type parameter mapMappable.A
which are linked to type parameters fromFEnum
[unit.issues.Issue9661] Unbound type parameter make.T
which is kind of a weird one (see issue/test)[unit.issues.Issue5385] Unbound type parameter fromIterable.T
, about Iterator anon fields being used at two places (because of inline?) with a type parameter that only exists at one place (some leak / mutation that shouldn't apply to the other expr / type parameter cleaning that is not applied to inlined expr ? Issue only happens incf_expr_unoptimized
(expr with problem is discarded because unused)