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

Hxb #11266

Closed
wants to merge 83 commits into from
Closed

Hxb #11266

wants to merge 83 commits into from

Conversation

kLabz
Copy link
Contributor

@kLabz kLabz commented Jun 29, 2023

Continued in #11504

Random TODOs:

  • still some unbound type parameters ¹
  • overloads
  • import as/in (would be fixed by using module_resolution branch)
  • rework anons added from another anon's fields
  • protocol version + crc handling
  • fix for very long file names (3090)
  • optimize positions

¹ Current type parameter issues:

  • [unit.TestGADT] Unbound type parameter EBinop.C which can be fixed by commenting out line 282 of src/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 from FEnum
  • [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 in cf_expr_unoptimized (expr with problem is discarded because unused)
  • Issue 4599, while not triggering errors on tests run here, gives unbound parameter errors on heaps projects

src/core/tFunctions.ml Outdated Show resolved Hide resolved
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;
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

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?

src/compiler/hxb/hxbWriter.ml Outdated Show resolved Hide resolved
@skial skial mentioned this pull request Jul 5, 2023
1 task
@kLabz kLabz force-pushed the hxb_reloaded branch 2 times, most recently from 39be59a to 5c2162f Compare July 10, 2023 09:32
@Simn
Copy link
Member

Simn commented Jul 11, 2023

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.

src/compiler/generate.ml Outdated Show resolved Hide resolved
src/compiler/hxb/hxbWriter.ml Outdated Show resolved Hide resolved
@Simn
Copy link
Member

Simn commented Jan 2, 2024

We will open a new PR from a different branch soon!

@Simn Simn closed this Jan 2, 2024
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.

2 participants