bump argo submodule

[pnwamk]

No description provided.

[pnwamk]

@RyanGlScott initially I naively put up this PR thinking it would address build issues resulting from the breaking changes to aeson in versions >= 2.0 (i.e., like those you addressed here), but shortly thereafter discovered (via a similar PR for saw-script) that there is some code in this repo that will need changed to cope with those aeson changes, e.g.:

[ 1 of 16] Compiling CryptolServer.Data.Type ( src/CryptolServer/Data/Type.hs, /home/jennifer/work/PICARD/saw-script/dist-newstyle/build/x86_64-linux/ghc-8.10.7/cryptol-remote-api-0.1.0.0/build/CryptolServer/Data/Type.o, /home/jennifer/work/PICARD/saw-script/dist-newstyle/build/x86_64-linux/ghc-8.10.7/cryptol-remote-api-0.1.0.0/build/CryptolServer/Data/Type.dyn_o ) [Cryptol.Utils.RecordMap changed]

src/CryptolServer/Data/Type.hs:222:25: error:
    • Couldn't match expected type ‘JSON.Key’ with actual type ‘T.Text’
    • In the first argument of ‘(.=)’, namely ‘T.pack (show (pp f))’
      In the expression: T.pack (show (pp f)) .= JSONType ns t'
      In the first argument of ‘JSON.object’, namely
        ‘[T.pack (show (pp f)) .= JSONType ns t' |
            (f, t') <- canonicalFields fields]’
    |
222 |           JSON.object [ T.pack (show (pp f)) .= JSONType ns t'
    |                         ^^^^^^^^^^^^^^^^^^^^

src/CryptolServer/Data/Type.hs:234:35: error:
    • Couldn't match type ‘Data.Aeson.KeyMap.KeyMap JSON.Value’
                     with ‘HM.HashMap k0 a0’
      Expected type: HM.HashMap k0 a0
        Actual type: JSON.Object
    • In the second argument of ‘HM.lookup’, namely ‘o’
      In the expression: HM.lookup "type" o
      In the expression:
        case HM.lookup "type" o of
          Just t -> asType t o
          Nothing
            -> case HM.lookup "prop" o of
                 Just p -> asProp p o
                 Nothing -> fail "Expected type or prop key"
    |
234 |             case HM.lookup "type" o of
    |                                   ^

src/CryptolServer/Data/Type.hs:237:39: error:
    • Couldn't match type ‘Data.Aeson.KeyMap.KeyMap JSON.Value’
                     with ‘HM.HashMap k1 a1’
      Expected type: HM.HashMap k1 a1
        Actual type: JSON.Object
    • In the second argument of ‘HM.lookup’, namely ‘o’
      In the expression: HM.lookup "prop" o
      In the expression:
        case HM.lookup "prop" o of
          Just p -> asProp p o
          Nothing -> fail "Expected type or prop key"
    |
237 |                 case HM.lookup "prop" o of
    |

For SAWScript I ended up just making < 2.0 the upper bound for aeson (in this PR as an easy band aid for now. Should we do that here as well? If we don't, I assume some CPP could make this code more robust... I'm hesitant to add such CPP when an upper bound will do (but perhaps I'm overly CPP averse and it's NBD). Thoughts?

[RyanGlScott]

Ah, I see. You're right in order to support aeson-2.0.* properly, we'll likely need to add CPP. But in the meantime, I think adding an upper bound of aeson < 2.0 would suffice. (Eventually, I hope to get around and bump all of these aeson upper bounds, but please don't wait on me for that.)