Throw TypeError for all input validation

[a-sully]

This PR removes all uses of DataError from the spec in favor of using TypeError for all input validation

Notably, all validation checks and output shape calculations related to operand axes/ranks/dimensions/shapes are treated as TypeError with the rationale that axes/ranks/dimensions/shapes do not constitute an operand's data, but its type (as C++ does, for example)

Fixes #583

---

Preview | Diff

[huningxin]

@a-sully , thanks for making this PR!

[a-sully]

We discussed this topic internally, kicked off by @inexorabletash's observation that RangeError is very rarely used in web specs...

Taking a step back, we should express as many of these constraints in the IDL (as opposed to the algorithm text) as possible. That's what #562 is all about. But many of these constraints are not (yet) expressible via WebIDL.

That leads to the question of what might a future WebIDL do if it added support for e.g. range validation, default non-empty sequences, etc? Ideally we could anticipate this and throw the appropriate errors for WebNN...

...Given that even the [EnforceRange] IDL extended attribute results in a TypeError (crazy! 🤯 Thanks @reillyeon for the pointer) I think that's a strong argument that these future WebIDL features would also use TypeError, and we should just throw TypeError for all synchronous input validation in WebNN

Thoughts?

[a-sully]

Apologies for the force-push (there were several conflicts) but the diff is just s/RangeError/TypeError

[huningxin]

LGTM, thanks @a-sully !

[huningxin]

@a-sully , you may want to update your first comment where

A few instances use RangeError - for example validating that the value of an options dictionary member is not zero.

it may not be true in the latest commit.

[a-sully]

Good catch @huningxin. I've updated the PR description and title. Please feel free to merge at your convenience

Thanks all for the reviews!

[a-sully]

Just kidding, I just noticed that @fdwr hasn't looked at this yet. Dwayne, PTAL and merge at your convenience, if it looks good :)

[fdwr]

For cases like these...

• If axis is greater than or equal to first’s rank, then throw a "DataError" DOMException.
• if any of its elements is not in the range 0 to input’s rank, exclusive, then throw a "DataError" DOMException.

...wouldn't they best be described as RangeErrors? I agree it's not about the data (so DataError "Provided data is inadequate." doesn't make so much sense), but it's really not about the data type either.

One good DataError case is:

• If the byte length of outputTensor is not equal to outputDesc’s byte length, then throw a "DataError" DOMException.

[fdwr]

(read Joshua's comment above)

🤔 Well I still think RangeError semantically makes much sense for cases like passing an axis parameter that is out of range for the rank. For [EnforceRange], TypeError actually makes sense to me too because it's specifically about data type conversion (from a double to a unsigned long). Though, I'm content to accept this change either way because the current [DataError] doesn't really make sense either, and the WebIDL spec here says "Use TypeError for invalid arguments". 🤷‍♂️

we should express as many of these constraints in the IDL (as opposed to the algorithm text) as possible

👍