Qqwy / elixir-type_check

TypeCheck: Fast and flexible runtime type-checking for your Elixir projects.
MIT License
516 stars 25 forks source link

Fresh LV project - compile time error with type_check #190

Open sushilbansal opened 3 months ago

sushilbansal commented 3 months ago

mix.exs:

      {:phoenix, "~> 1.7.14"},
      {:phoenix_ecto, "~> 4.5"},
      {:ecto_sql, "~> 3.10"},
      {:postgrex, ">= 0.0.0"},
      {:phoenix_html, "~> 4.1"},
      {:phoenix_live_reload, "~> 1.2", only: :dev},
      # TODO bump on release to {:phoenix_live_view, "~> 1.0.0"},
      {:phoenix_live_view, "~> 1.0.0-rc.1", override: true},
      {:type_check, "~> 0.13.5"},

compile time error:

    error: undefined function .../0 (expected TypeCheck.Internals.UserTypes.TypeCheck.DefaultOverrides.Macro to define such a function or for it to be imported, but none are available)
    │
  4 │   @type! captured_remote_function() :: (... -> any())
    │                                         ^^^
    │
    └─ lib/type_check/default_overrides/macro.ex:4:41: TypeCheck.Internals.UserTypes.TypeCheck.DefaultOverrides.Macro.captured_remote_function/0

== Compilation error in file lib/type_check/default_overrides/macro.ex ==
** (CompileError) lib/type_check/default_overrides/macro.ex: cannot compile module TypeCheck.Internals.UserTypes.TypeCheck.DefaultOverrides.Macro (errors have been logged)
    expanding macro: TypeCheck.Macros.__before_compile__/1
    lib/type_check/default_overrides/macro.ex:1: TypeCheck.DefaultOverrides.Macro (module)
could not compile dependency :type_check, "mix compile" failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile type_check --force", update it with "mix deps.update type_check" or clean it with "mix deps.clean type_check"
sushilbansal commented 3 months ago

upon further investigation, the issue occured with elixir v 1.17.2-otp-27 but if i switch back to the previous version i was using, then there are no issues: 1.16.0-otp-26

spacebat commented 3 months ago

I'm also getting this, elixir v 1.17.1-otp-27

spacebat commented 3 months ago

I suspect this bugfix mentioned in the changelog for Elixir 1.17.0 might be a clue: [Kernel] Resolve inconsistencies of how .. and ... are handled at the AST level

maruks commented 3 months ago

I'm also getting this,

Erlang/OTP 27 [erts-15.0] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit]

Elixir 1.17.1 (compiled with Erlang/OTP 27)
Qqwy commented 2 months ago

Thank you very much for reporting! Your conclusion seems correct: TypeCheck integrates (/has to integrate) quite closely with Elixir's AST to work correctly (since it parses the builtin typespec syntax), but it seems that in the change from v1.16 to v1.17 the way ... is handled has changed.

So for the time being, it seems that TypeCheck doesn't work on Elixir v1.17.

Unfortunately I am on vacation with no laptop close at hand until the start of August. If anyone is able to contribute a fix in the meantime I'll merge and publish that PR as soon as possible. Otherwise, please hang tight until the start of August.

I'm sorry for the inconvenience 😔.

Qqwy commented 2 months ago

Specifically I think that

https://github.com/Qqwy/elixir-type_check/blob/ba2610edd6b29d7f91a2c8ce108431ea078bdb23/lib/type_check/internals/pre_expander.ex#L92

will need a change. That is the pattern match that should handle (... -> any) but it seems to no longer trigger.

skwerlman commented 1 month ago

i took a look today, and it seems 1.17 has an empty list instead of the module name as the 3rd element in the tuple. I'm unsure if this is the correct way to fix this, but changing the guard to accept the empty list in that position allowed it to compile on 1.17.2:

[[{:..., _, module}], return_type] when is_atom(module) or module == [] ->

i'll open a pr with the change, but if theres anything obviously incorrect about it, feel free to close it or point me in the correct direction