Error rework

[lue-bird]

Refactoring simplify is a bottomless pit. In other languages, I think I wouldn't even bother starting but in elm it's fun :white_flower:

changes

• change errors from a list to a maybe
• add fn name and module name to check infos so that the function name doesn't have to be passed to both the checks and the tuple of the dict element
• consistently use a more concise description for all empty constants, e.g. "[]" instead of "an empty list"
• use identityError (now called alwaysReturnsLastArgError) wherever toIdentityFix was used
• use new alwaysResultsInConstantError wherever alwaysResultsInFix was used
• use findMapNeighboring more often, e.g. instead of findEmptyLiteral
• transform all uses of alwaysResultsInFix to new alwaysResultsInConstantError for more correct errors
• Use precise descriptions for constructor, constructed and value inside constructed, e.g. "Just", "just maybe", "value inside the just maybe"
• return { info, fix } from compositionChecks, instead of Error {} because fnRange is always used as the error range
• introduce lots of generic checks

cool stuff this PR enables

Adding generic checks for map, andThen etc (mostly thanks to the new WrapperProperties) makes it very easy to apply these checks for Random.andThen, Fuzz.andThen etc.

I've intentionally not added specific cases to existing function checks in this PR* to keep it focused, e.g not

• using emptiableAndThenChecks for resultAndThenChecks
• adding irrelevantEmptyElementInGivenListArgCheck to listFilterMapChecks
• adding ( ( [ "String" ], "fromChar" ), wrapperFromListSingletonCompositionChecks stringCollection )
• adding callOnSingletonListDoesNotChangeItCheck checkInfo.firstArg to existing reverse checks or adding mapWrapChecks listCollection to listMapChecks
• adding ( ( [ "List" ], "concatMap" ), mapToOperationWithIdentityCanBeCombinedToOperationCompositionChecks { mapFn = ( [ "List" ], "map" ) } ).

Adding those low-hanging fruits could be done in a future PR.

* I did add 2 things: 1, List.member (List.singleton b) b --> b == b with expectNaN + edited test. Looking at the previous implementation, this seems to have been a bug. I also tested that member and == give the same result for NaN. 2, List.concatMap List.singleton x --> x + tests. Excluding it would have been quite a bit more work.

discussion

• I feel like starting with Using, Calling etc. adds mostly noise to the error messages

  Using String.slice with end index 0 will result in an empty string

  String.slice with end index 0 will result in an empty string

  I think adding using/calling/.. is a bit more readable and correct but it doesn't convey the actual information as quickly / doesn't feel as focused.

git

The technique you showed with stash push and pop worked wonderfully!

funny errors that were fixed

There were some really cursed errors in there, so far my favorite is

{ message = "The result of String.replace will be the original string"
, details = [ "The replacement doesn't haven't any noticeable impact. You can remove the call to String.replace." ]
}

[jfmengels]

All looks great so far :blush:

[lue-bird]

Oki, 444 commits, ready to review!