Bad error messages on some `transfer`s
Using a bug template, but arguably it's not really a "bug", but just "bad UX" due to stuck type families.
Description
In some cases, transfer
can produce very arcane compile-time error messages. Consider this example:
_example :: (MonadCleveland caps m, NiceParameter cp) => ContractHandle cp st vd -> m ()
_example ch = transfer ch (123 :: Mutez)
The error message reads:
• Could not deduce: first-class-families-0.8.0.1:Fcf.Core.Eval
(first-class-families-0.8.0.1:Fcf.Data.Common.FromMaybe
cp
(first-class-families-0.8.0.1:Fcf.Core.Eval
(EpdLookupEntrypoint
(Data.Type.Bool.If
(Lorentz.Entrypoints.Helpers.CanHaveEntrypoints cp)
(ParameterEntrypointsDerivation cp)
EpdNone)
cp
Lorentz.Entrypoints.Core.DefaultEpName)))
~ ()
arising from a use of ‘transfer’
Pretty horrible. The actual reason this fails is ContractHandle
uses checked transfer by default, and it tries to check cp
indeed has a default entrypoint with unit
argument. There is no information about that in scope, however, and hence the type family gets stuck.
The culprit is HasEntrypointArg
typeclass, specifically, the GetEntrypointArgCustom
type family gets stuck.
We could try to use WhenStuck from type-errors to try to produce a more readable error message on HasEntrypointArg
instance, at least.
Steps to reproduce
See above
Expected behaviour
The user is notified that it's impossible to deduce whether the contract has an entrypoint with the given name and the given type, and suggests adding constraints and/or using unchecked version of transfer.
Actual behaviour
GHC spits out a wall of arcane spells at the user
Environment
2d4f0cd3 (current master)