@surik, change looks sane, i've just now noticed we've got no test coverage on the dia compiler.
Would you be available to write a small test to improve rebar coverage? If not, then real world .dia files would also be helpful.

I added a small test for dia compiler and this test shows that compiler doesn't work on OTP 14 because uses undefined function diameter_dict_util:parse/2

I see, maybe that explains why there were no tests.
We can check for versions older than R15 and ignore the test for those. rebar_reltool.erl already does this (see check_vsn/0).
Also should we not be checking for correct output from the dia compiler? A simple comparison with a static string of the expected output would suffice.
For both checking the OTP version and the expected output maybe Eunit tests are a bit limited, integration tests (in the inttest/ folder) perhaps are more suitable for this case, you can find a similar test in inttest/proto_gpb, it takes a .proto file and compiles it to .erl while checking for correct output.
I understand that this has a bit more scope than you intended with the original PR, please let me know if you need a hand with this, i'll be glad to collaborate with you and take this chance to improve rebar's support of diameter compiling.

I added ignoring test for dia compiler on OTP < 15.

Tests on R16B02 are broken and looks this is not related to my changes.

Tests on R16B02 are broken and looks this is not related to my changes.

They were not, there's one specific test (ct1_rt) that needs a larger timeout

Also should we not be checking for correct output from the dia compiler? A simple comparison with a static string of the expected output would suffice.
For both checking the OTP version and the expected output maybe Eunit tests are a bit limited, integration tests (in the inttest/ folder) perhaps are more suitable for this case, you can find a similar test in inttest/proto_gpb, it takes a .proto file and compiles it to .erl while checking for correct output.

What are your thoughts on this subject?

What are your thoughts on this subject?

I fixed a small issue and provided a test which shows that it is works well. EUnit is enough in this case. What would be a different with inttest?

Maybe we can write a better test for dia compiler in inttest but in my opinion it is out of scope of this PR.

I fixed a small issue and provided a test which shows that it is works well. EUnit is enough in this case. What would be a different with inttest?

The test shows that something was compiled, a complete test would show that the output format is as expected. Eunit is apropriate for unit testing, inttest allows for more complex checks (integrity, making sure that the file is not compiled more than once unnecessarily, etc).

Maybe we can write a better test for dia compiler in inttest but in my opinion it is out of scope of this PR.

I understand, that's why i offered my help in making this a more complete PR that contains tests. If this is not possible i'd prefer this PR with just the fix and i'll propose a separate PR with more thorough testing.
What are your thoughts on this @Tuncer?

+1 then, maybe squash 99d1c5a and 60861a4 first?

Squashed

Thanks, if you wish please add your name to the THANKS file if not already there