Is Dialyzer fetching incorrect specs, or are they incorrect in Meeseeks?

sztosz

defmodule A do
  def x() do
    Meeseeks.parse("<div id=main><p>Hello, Meeseeks!</p></div>")
  end
end

This gives me this error:

The call:
Meeseeks.parse(<<_::336>>)

will never return since it differs in arguments with
positions 1 from the success typing arguments:

(
  [
    binary()
    | {:comment, binary()}
    | {:pi, binary()}
    | {:pi | binary(), binary() | [{_, _}], binary() | [any()]}
    | {:doctype, binary(), binary(), binary()}
  ]
  | {:comment, binary()}
  | {:pi, binary()}
  | {:pi | binary(), binary() | [{binary(), binary()}], binary() | [any()]}
  | {:doctype, binary(), binary(), binary()}
)

When the specs for Meeseeks.parse is @spec parse(Parser.source()) :: Document.t() | {:error, Error.t()} with Parser.source() being @type source :: String.t() | TupleTree.t() and then TupleTree.t() being

  @type comment :: {:comment, String.t()}
  @type doctype :: {:doctype, String.t(), String.t(), String.t()}
  @type element :: {String.t(), [{String.t(), String.t()}], [node_t]}
  @type processing_instruction ::
          {:pi, String.t()}
          | {:pi, String.t(), [{String.t(), String.t()}]}
          | {:pi, String.t(), String.t()}
  @type text :: String.t()
  @type node_t :: comment | doctype | element | processing_instruction | text
  @type t :: node_t | [node_t]

Dialyxir and Dialyzer helped ma lot, but I don’t understand what’s wrong with those specs, or is it bug with tools rather.

If source :: String.t() | TupleTree.t() or source :: binary() | TupleTree.t() then call Meeseeks.parse(<<_::336>>) where <<_::336>> is binary should satisfy those specs. Right?

Beside, even when dialyxir/dialyzer says [...] will never return since [...] actually when run always returns and simply works OK.

21 comments

#dialyzer #meeseeks #dialyxir

2 2375 21

2018-06-15 19:22:04 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

jeremyjh

It looks like Dialyzer is finding the success type of the arg as list(Parser.source()) | Parser.source(), rather than the defined spec which is just Parser.source(). You could try fixing the spec in your local deps to and mix deps.compile meeseeks to try that out.

Post #1

sztosz

I really am not sure how to fix them, any pointers?

Post #2

jeremyjh

What I’m suggesting is just change above spec to what appears to be the success typing:

@spec parse(list(Parser.source()) | Parser.source()) :: Document.t() | {:error, Error.t()}

Post #3

jeremyjh

Actually that is a problem but probably not YOUR problem. Your problem appears to be that binary is not accepted unless its in a list, so you’d change your call to Meeseeks.parse(["<div id=main><p>Hello, Meeseeks!</p></div>"]). I’m not sure why it would work and not generate a compatible success typing, its an issue in that library though.

Post #4

sztosz

Changing it into list does not work sadly

I am not sure why dialyxir thinks that success typings is binary in a list etc `[binary() | … ] that is what I mainly try to understand.

Post #5

jeremyjh

Its due to a discontinuity in that spec versus the implementation of that function. What happens if you just remove the @spec from parse ?

Post #6

sztosz

I think dialyzer does not recompile its spec internally after commenting specs in meeseks, because errors are the same. I’ll try with fresh environment and simple project later this week, but can’t do it now, too much work

Post #7

jeremyjh

Did you run mix deps.compile meeseeks ? Dependencies are not recompiled automatically.

Post #8

sztosz

I did mix deps.compile after changing and it did recompiled meeseeks.

Post #9

mischov

I’m pretty sure that list in the success typing there is because of @type t :: node_t | [node_t] in the TupleTree.t(), which should list every node type as contents of a list, but also every node type singularly.

However, it’s very interesting that
a) while the list of node_t properly contains binaries (representing text nodes), binary() isn’t included as a single node outside of the list as it properly should
b) a top level binary() isn’t provided since it should be included because of String.t() | TupleTree.().

Edit: This does highlight a logical problem when it comes to parsing, but I don’t think it should affect Dialyzer.

Post #10

Load more posts (11 remaining)