* Not clean `nix-review`:

vhd2vl fixed in 80b75cd86cbefd4fa3da321617e92a75808529de

Had to rebase because of the 58a906a

@prusnak This is a follow up to your comment on 58a906a:

First, I'm terribly sorry for causing you troubles. I wasn't aware of this PR; otherwise, I simply would have merged it instead of authoring my own. I want to get that clear off the bat, since this PR is clearly higher quality than my original quick update.

Second: the reason I merged this was actually due to a mistake on my part. When I was doing updates of yosys (now part of e80eeae), I ran into a bug where the test suite started failing due to a recent overhaul done to it, enabling parallel tests. In brief, there's a small script in the test suite that erroneously states "ERROR: Please try updating your icarus verilog version" which I had done in the past. So I committed a change for that (58a906a), rebased, tried again and.... it failed. Turns out, the test suite failed for another reason (an implicit dependency on a file named ./yosys-abc, which was an unnoticed change in the build.)

I simply did not remove the iverilog commit when I fixed this, and accidentally left it in as it was harmless (and again, I wasn't aware of this PR.) I also made the mistake of using master when, as you noted, I should have used the new fresh 12.0 release. Yosys required the unstable branch until now, and this was simply an oversight; I literally just typed git pull origin master on my copy of Icarus and used the latest hash, not even checking the tag. Again, we should use 12.0 until otherwise necessary. I suspect yosys would be the only reason to go back to an unstable release, but it may be better to simply add a verilog-unstable package, instead.

Third: I wasn't aware of this PR because I wasn't marked as the maintainer, so I was not CC'd on it. I do not scan nixpkgs PRs by hand; I use and rely GitHub notifications because I maintain too much stuff anyway. And while my latency is high these days, in particular I maintain many of the related VLSI/RTL/FPGA related packages in Nixpkgs, and adopt more often. This is only to to try and help ensure a consistent level of quality among them; so as part of 58a906a I also adopted Icarus (as the original maintainer has been absent for quite some time, which happens.) If I had adopted it earlier, I would have seen this PR since borg would have mentioned me.

Finally, I didn't PR my original changes because, frankly, I am an old curmudgeon who pushes to, and only uses, master everywhere (I think this will be my 6th or 7th year of being a committer?) and few other users regularly submit substantial updates to these packages besides myself. Thus reviews simply tend to add latency and hold back bugfixes/improvements for users rather than actually achieve anything other than surface level "LGTM" reviews. This isn't always true of many or even most packages though. And it might seem paradoxical: if nobody submits PRs, are there any users besides me? But I think this is expected: people do not actually need to submit updates normally because the packages are, mostly, quite high quality and full featured already, if I do say so myself. Furthermore, most of the FOSS RTL/VLSI tools are still evolving new features and capabilities regularly, so thorough, high-quality updates that enable those features in a maintainable way involves more than just bumping patch versions. And random people who aren't familiar with the tools are going to have difficult times ensuring those features work well. That isn't to say your patches are not high quality or that Icarus is some high-speed, fast moving target; it's just an explanation of my thought process for pushing directly to master in many cases, not just this one. And this position certainly isn't immune to criticism either or anything, so if you feel put off by just overwriting things, I understand and apologize.

Having said all that: these patches look fine to me, so thank you for your patience. I'll merge them!

First, I'm terribly sorry for causing you troubles.

No worries! First, these things happen. No harm done, it took me like 2 minutes to rebase this PR.

Second, I really wanted to understand the situation; especially with verilog, there might've been thousands of valid reasons why using unstable was preferred to latest stable even in case these are couple of days apart.

Thanks for your explanation!