s/spec seems like a good candidate for a symbolic spec, but it currently can't be used as one.
This is because s/spec does not implement s/create-spec or s/expand-spec.
The naive fix CLJ-2562-symbolic-s-spec.patch isn’t entirely satisfactory because s/spec is always lost after a s/resolve-spec. This means the semantics of regex specs aren’t preserved with a (s/form (s/resolve-spec %)) roundtrip.
For example, with just CLJ-2562-symbolic-s-spec.patch we have:
A more satisfactory fix CLJ-2562-symbolic-s-spec-roundtrip.patch proposes a solution to this by attaching the original s/spec form to resolved specs at the ::s/wrap-spec key. Then, the s/describe logic for regex specs can read the entry when appropriate.
Implements s/expand-spec and s/create-spec for s/spec
Problem: does not roundtrip with regex specs
Like patch 1, but also ensures s/spec is preserved in s/form for regex specs