Eliminate Shift/Reduce Parse Warnings

[asummers]

These indicate issues in the parser grammar. My lexing and parsing rules were largely done by brute force as I grew to understand the Dialyzer output, and they have some things to work on, but I'm pretty unsure of how to resolve these warnings. I've gone back through the grammar rules a few times to try and minimize its clauses a few times, but can't see where it's upset, and am unsure how to have the tooling help me here.

[amatalai]

It's possible to make it more verbose in mix.exs config

def project do
  [
    app: :dialyxir,
    elixir: ">= 1.6.0",
    # ...  
    yecc_options: [verbose: true],
    # ...
  ]
end

Also, part of yecc documentation (http://erlang.org/doc/man/yecc.html) suggests that some shift/reduce conflicts may be expected

The optional expect declaration can be placed anywhere before the last optional section with Erlang code. It is used for suppressing the warning about conflicts that is ordinarily given if the grammar is ambiguous. An example:
Expect 2.
The warning is given if the number of shift/reduce conflicts differs from 2, or if there are reduce/reduce conflicts.

[asummers]

That seems useful! Thank you.

[asummers]

Okay so after basically just deleting a bunch of code in the parser, it seems like the parser doesn't like self referencing terminals, I think. I believe this can be solved with precedence rules, but haven't played with those yet, After removing most of the atom rules and the named_type rules and checking the warning count, it dropped by 14 or 15. Clearly there's an issue with some of those rules, but I'm not sure how to fix quite yet. If you remove those (just assuming they're fixed for accounting purposes), there are 9 issues remaining, and I'm unsure where those come from yet. But solving those two issues would go a long way to fixing these.

Current warning count: 23 after a PR I'm about to make.

[asummers]

After #218, current warning count will be 19. Seems like most of the errors after that are in the atom definition as well as the pipe_list definition. Commenting atom to leave just the atom_full line, to remain functional out leaves us with 11 errors. and then commenting out the pipe_list lines then taken us from 11 to 6. I can see pipe_list being an issue of precedence.

[asummers]

Seems like it really, really hates these two lines:

% atom -> atom integer : '$1' ++ ['$2'].
% atom -> atom atom : '$1' ++ '$2'.

They're responsible for 8 of the remaining 19 errors.

[asummers]

This is now an Erlex problem.