Extremely large wires in generated RTLIL produce confusing parser errors

[WRansohoff]

Steps to reproduce the issue

Attempt to parse the following RTLIL:

attribute \generator "nMigen"
attribute \top 1
attribute \nmigen.hierarchy "top"
module \top
  wire width 32 \y
  wire width 4294967327 $1
  wire width 32 \a
  wire width 32 \b
  wire width 4294967327 $2
  cell $sshl $3
    parameter \A_SIGNED 1'0 
    parameter \A_WIDTH 6'100000
    parameter \B_SIGNED 1'0 
    parameter \B_WIDTH 6'100000
    parameter \Y_WIDTH 33'100000000000000000000000000011111
    connect \A \a
    connect \B \b
    connect \Y $2
  end 
  connect $1 $2
  process $group_0
    assign \y 32'00000000000000000000000000000000
    assign \y $1 [31:0]
    sync init
  end 
  connect \a 32'00000000000000000000000000000000
  connect \b 32'00000000000000000000000000000000
end

To test, save the above RTLIL as bug.il and run:

yosys -q -p "read_ilang bug.il; write_verilog bug.v;"

Observe:

ERROR: Parser error in line 24: invalid slice

Expected behavior

The above RTLIL was created by a code generator. It seems unlikely that a designer would intentionally create a wire that is 4 billion bits wide, so it might be nice to produce a warning or error which points to the oversized wire instead of (or in addition to) printing an error at the attempt to slice that wire.

As someone who is still learning the toolchain, it was not immediately clear to me why the parser complained about slicing the first 32 bits out of a value, but I can understand that a wire should not be billions of bits wide under normal circumstances.

Actual behavior

The parser points to this line as the source of the problem:

assign \y $1 [31:0]

In a larger design, the problematic RTLIL line will probably be located among many similar (and valid) statements, which makes it harder to track down the real source of the problem.

In my case, I was designing an ALU with a variety of operations, and only the left-shift one produced this issue. When I looked at the RTLIL line which Yosys me pointed to, I couldn't tell why that particular assign \y statement would cause issues when it was surrounded by dozens of almost identical statements which the parser seemed happy with.

Thank you!

[whitequark]

See #1875.