Not necessarily a bug, but..

[seanyoung]

There are a bunch of cases that aren't really correct, but IrpTransmogrifier accepts them anyway.

carrier specified twice: {20k,10k}<1,-1|1,-3>(10:4,-100)

stream in bitspec is only complained about when it is evaluated. Might be good to always error: {}<1,(A,10)+>() is ok {}<1,(A,10)+>(0:1) is not ok

definition depends on itself causes stack overflow: {10k}<1,-1|1,-3>(C:4,-100){C=10*C}

two definitions for same variable is also accepted: {10k}<1,-1|1,-3>(C:4,-100){C=10,C=20}

[seanyoung]

Another one:

{10k}<1,-1|1,-3>(10:4,-100)10010101

This will take forever to render (if it ever finishes). My rust irp implementation limits the repeat markers to 64, like bit fields.

[bengtmartensson]

carrier specified twice:

This is documented, not a bug.

stream in bitspec is only complained about when it is evaluated. Might be good to always error: {}<1,(A,10)+>() is ok {}<1,(A,10)+>(0:1) is not ok

The second one actually produces a correct error message, but you seem to have missed it. After following the error message and adding a trailing gap, it is ok. The BitSpec given is grammatically correct.

definition depends on itself causes stack overflow:

I do not consider this an error.

two definitions for same variable is also accepted:

Documented, i.e. explicitly allowed.

{10k}<1,-1|1,-3>(10:4,-100)10010101

This will take forever to render (if it ever finishes). My rust irp implementation limits the repeat markers to 64, like bit fields.

Free software means, among other things, freedom from arbitrary restrictions. I recommend you to remove it from your implementation.

Free software deliver the result the user asks for, to the extent possible. It does not tell the user that his/her input is stupid.