please wrap code that type-checks an expression in a try-catch which prints the file and line of the expression in the catch clause so that expressions causing internal errors can be found

[dsw]

Feature request / proposal.

Impact:

• much easier for the user to minimize files which cause internal errors so they can be reported to you and
• much easier for the user to guess the problem in their input and work around it.

I have noticed that sometimes internal errors / raw stack traces from FIRRTL make no mention of the location within the input file that was being processed when the internal error occurred.

To report the error, the user has no choice but to use a tool like a delta debugger to minimize the file that causing the internal error. I have done this twice and it can be very slow, taking more than a day each time, and several hours of my time manually minimizing further after delta was done.

In this situation it would help greatly just to know what syntax was being processed when the error occurred. It might not point to the exact problem, but it is at least a likely guess, which helps a lot when doing delta debugging.

Therefore I suggest that the following simple changed would help substantially:

• for each pass over the syntax (such as type checking), wrap a try {...} catch (Exception e) {...} around the call into the code that processes a particular expression, and
• in the catch clause print out the file and line number of the expression (and maybe also a dump of the expression syntax) and then re-throw the exception.

Now, if there is an internal error, then at least the user knows where in the input file the syntax occurs that was being processed when the internal error occurred. This would help a lot.