[#906] Better errors on stuck GetEntrypointArgCustom
No bright ideas on how to test this. Tried using deferred type errors, but those apparently don't capture custom TypeError
s.
One curious side effect is that in some cases, constraint arg ~ GetEntrypointArgCustom cp mname
would have to be replaced with HasEntrypointArg cp (EntrypointRef mname) arg
. AFAICT, this is an equivalent transformation: this would be required only when polymorphic code actually wants HasEntrypointArg
constraint, but it was provided by providing the instance constraints instead.
Description
Problem: HasEntrypointArg
has an equality constraint on
GetEntrypointArgCustom
in one of its instances. The latter can get
stuck in polymorphic code, which produces pretty unreadable error
messages due to using first-class-families under the hood. This might be
fine when GetEntrypointArgCustom
is used directly, but when FCFs leak
into high-level user code using HasEntrypointArg
, perhaps indirectly,
it's not ideal. The motivating example is transfer
from Cleveland.
Solution: Detect when GetEntrypointArgCustom
gets stuck in
HasEntrypointArg
constraints and print a more user-friendly error
message, suggesting adding the appropriate constraint explicitly.
Related issue(s)
Resolves #906 (closed)
✅ Checklist for your Merge Request
Related changes (conditional)
-
Tests (see short guidelines)
-
If I added new functionality, I added tests covering it. -
If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.
-
-
Documentation
Stylistic guide (mandatory)
-
My commits comply with the following policy. -
My code complies with the style guide.