Fails to report spec error when a non-fn IFn value doesn't conform to a fspec about expound HOT 5 CLOSED

Thanks very much for reporting this bug!

This is a tricky one to solve in general.

A little context: Expound uses the data returned by explain-data to print an error message.

This "explain-data" contains a "value" (which is the top-level form) and a sequence of problems, each of which contains (among other things) a "val" (which points to the bad value) and an "in" (which is the path to the bad value). For example:

(require '[clojure.spec.alpha :as s])
(s/explain-data (s/coll-of int?) [1 2 :a])

;; explain-data is:
;; #:clojure.spec.alpha{:problems ({:path [], :pred int?, :val :a, :via [], :in [2]}), :spec #object[clojure.spec.alpha$every_impl$reify__934 0xdfe0a61 "clojure.spec.alpha$every_impl$reify__934@dfe0a61"], :value [1 2 :a]}

In this example, there is just one "problem". The value is [1 2 :a], the val is :a and the :in is [2].

In this simple case, the :in path is easy to interpret. However, in general, there are cases where it's tricky to figure out how to interpret the :in path - see https://dev.clojure.org/jira/browse/CLJ-2192

Expound has a lot of code dedicated to figuring out the :in path. One heuristic I use is that the :val should be located somewhere within the :value (that is, the part of the data that is invalid should exist within the top-level form).

However, in the case of fspec failures, this assumption is not true - see https://dev.clojure.org/jira/browse/CLJ-2258

As a result, we get this bug - Expound can't figure out how to interpret the :in path and crashes.

My first impression is that it's not possible to solve this in general until one or both of the above Jira issues are fixed. However, there may be a way to solve this in at least some cases. I'll think more about this.

from expound.

@athos I've released version 0.3.3 which contains this fix. Thanks for your help!

from expound.

@athos Thanks again for reporting this! I don't think it's possible to fix this in every case, but I think I have a heuristic for the more common cases. Can you try out 0.3.3-SNAPSHOT and see if it works in your case?

from expound.

Thank you for the quick reply and polite explanation about the context.
I'm a little bit familiar with those things since I'm also working on a library similar to Expound (named Pinpointer) for more than a year 😃

I looked into the issue today, and now I see the difficulty of giving a general solution to it. In general, a return value generated by a fspec could not be mapped into the input value, which is a very similar situation where a conformer transforms the input value.

So, yeah, I think your new PR now resolves the issue to some extent, and it would be sufficient for practical problems IMHO.

from expound.

@athos

I'm a little bit familiar with those things since I'm also working on a library similar to Expound (named Pinpointer) for more than a year

Excellent! I took a quick look at Pinpointer and it looks great! I'll look take a look at Jira issues you've opened for spec and vote them up. Anything that makes it easier to build something like Expound or Pinpointer helps everyone :)

from expound.