c1a39bbd

By: Tom Sydney Kerckhove <syd@cs-syd.eu>

Report an error type that is prose with a name on it

A signature reported for its String is answered by naming the String: write
type ParseError = Text, or wrap it in a newtype, and the rule that asked for a
type of its own is satisfied by a type that is still one undifferentiated
message. Both are now reported, read off the declaration's name, which is the
one thing that says a type is meant as a failure.

A wrapper counts only when its constructor is the type's name over again, with
or without Mk. That is the shape a reader learns nothing from, and its renderer
is id: renderNarInfoParseError (NarInfoParseError s) = s. A constructor that
names the failure is a different thing even when it is the only one.
UnknownRepoType !Text holds the input nobody understood rather than words about
it, and what a reader is told comes from the renderer that matches on the name.

The narrowing is the whole of the difference between a rule worth having and
one worth turning off. Over nix-ci8, smos, salsa, kronor, sydtest, validity and
graphql-engine, reporting every one-constructor wrapper found seventeen, and
fourteen of them were that second shape, written deliberately. Reporting only
the echo finds three, and all three have a renderer that hands back what it was
given. good.hs holds the shape that is left alone.

A data declaration with two constructors is the fix, so it is never reported.

Total

8s

Created 3 weeks ago Started 3 weeks ago Finished 3 weeks ago

Timeline