We need a way to express broadcastability constraints on the static shape values in TensorType.shape so that we can distinguish between the "no information" and "dimension is not broadcastable" cases, or anything similar.

We could always consider allowing -1 to encode a "not equal to 1" (i.e. not broadcastable) constraint on TensorType.shape values. I believe this has come up before, and it isn't perhaps the most desirable approach, but it should serve to adequately express the old TensorType.broadcastable constraints while also allowing TensorType.shape[d] == None to represent a complete lack of shape information—as it intuitively does.

We would need to refactor our current usage of TensorType.shape to account for this case, but, aside from being a less than exciting task, it shouldn't be particularly difficult.

Making this change would finally allow us to reason more definitively about some ambiguous instances of compile-time broadcasting, and help us remove some of the strong and unreliable assumptions we are currently required to make in our constructors and rewrites.

More specifically, it would help us raise errors when—for example—gradients are constructed, as in #1089. However, for that case specifically, some things still need to be worked out. For instance, it's not entirely clear which default non-broadcastability assumptions/constraints we should make in certain places, or simply whether or not there are even acceptable defaults possible.