我得到编译错误.但它不在foo中,它在bar中.它说:
错误:onlineapp.bar!(foo)模板实例与x=foo(T)(T v)的bar(alias x)()模板声明不匹配,必须满足__traits(compiles,x(1))约束.
我一般是提取约束模板并实际用该类型调用约束中的函数,然后查看失败原因.这有点烦人,有时很难根据实现约束的代码点及实际调用点来找.
此问题乏味但可靠的方法是用-verrors=spec重新编译,在输出中搜索原始错误消息,然后向上滚动,直到推测错误中找到要查找的内容.唯一问题是,必须翻阅大量无用信息才能找到真正关心的信息.
我认为,更容易的最佳方法是让编译器在模板无法实例化时为每个失败的约束提供推测错误的"堆栈跟踪",可能在开关后面(-verrors=constraints)来避免阻塞在常见情况下提高输出.
好处是可处理*所有*这样的间接错误,而不仅仅是涉及IFTI的错误.如,-verrors=constraints可以帮助我解决最近必须在SumType的复制构造器中调试的问题,而__traits(canCall)完全没用.
SumType的复制构造器由于编译器错误而失败,但我得到的错误是,
src/sumtype.d(1412,4):错误:静态断言:“模板类型的handlers[0]从不匹配”
因为复制构造器内部使用match,处理器无法推测性编译时,match给的错误.打开-verrors=spec可让我看到导致推断编译失败的处理器内部的错误:
(spec:1)src/sumtype.d-mixin-407(407):错误:Storage联有构造器,不能使用{初化器},改用Storage(initializers)
这就是导致我诊断并最终解决20842问题的原因.