Unparseable custom attribute colors cause a crash

[byorgey]

Describe the bug
In a scenario description, if the fg or bg color specification in a custom attribute cannot be parsed, swarm crashes.

To Reproduce

Try loading the following scenario .yaml file:

version: 1
name: Custom attribute - invalid color
description: |
  Invalid color in custom attribute
creative: false
attrs:
  - name: bogus
    bg: "this is not a color"
terrains:
  - name: whatzit
    attr: bogus
    description: |
      A thingy
robots:
  - name: base
    dir: east
world:
  dsl: |
    {grass}
  palette:
    'B': [grass, null, base]
    '.': [whatzit]
  upperleft: [0, 0]
  map: |
    B.

This results in:

$ ./scripts/play.sh -i Testing/_Validation/unparseable-attr-color.yaml
swarm: Data.Colour.SRGB.sRGB24read: no parse
CallStack (from HasCallStack):
  error, called at ./Data/Colour/SRGB.hs:128:3 in colour-2.3.6-01a45f2577c459ed9632a48ba99a66e313619b5bf990fc54e630e96fb26912b8:Data.Colour.SRGB

Note that the scenario successfully validates and loads; the error is thrown sometime later, perhaps when it is being rendered.

Expected behavior
The scenario should fail to validate with a reasonable error message.

[byorgey]

@kostmo So it looks like we store colors in the HexColor newtype, which contains Text. But as far as I can tell, the only thing we ever do with the Text in a HexColor is call sRGB24read . T.unpack on it in various places (which can crash). Is there any reason to not just parse + validate a hex color once and for all, and store a Kolor inside the HexColor instead?

I might be missing something here. I remember there were some strange issues with color palettes + conversions that you had to work around.

Edited to add: after trying a little refactoring it seems the only thing really standing in our way is that HexColor needs an Ord instance to work with an OccurrenceEncoder, but Colour a does not have an Ord instance. I'll have to think about this a bit more but it seems like it should be possible to make one.

Edited to add, pt 2: indeed, it was straightforward.