Exception in thread "main" firrtl.FirrtlInternalException: No width: UnknownType

[dsw]

bug report

What is the current behavior?

$ cat input1.firrtl 
circuit main :
  module main :
    node a = dshl(UInt<64>(0), rem(UInt<1>(1), SInt<32>(0)))

$ java -cp firrtl.jar firrtl.stage.FirrtlMain -o /dev/null -i input1.firrtl 2>&1 | head -1
Exception in thread "main" firrtl.FirrtlInternalException: No width: UnknownType

Please tell us about your environment:

Using firrtl-1.5.2.

$ uname -srio
Linux 4.4.0-31-generic x86_64 GNU/Linux

[seldridge]

To clarify: the bug is that the SFC should reject this circuit because rem(UInt, SInt) is illegal. This has to be either rem(UInt, UInt) or rem(SInt, SInt). CInferTypes is crashing when it sees this.

Example MFC output (which looks to be doing the right thing):

Foo.fir:3:32: error: operand signedness must match
    node a = dshl(UInt<64>(0), rem(UInt<1>(1), SInt<32>(0)))
                               ^

[dsw]

Yes, the error is the fact that this is an internal error, which no input should be able to cause.

[dsw]

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

I suggest that a simple changed could mitigate this situation substantially:

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

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