[spec] Omit "in:" spec problem info when reporting if all indexes

Description

When reporting spec problems, function arg problems are almost always positional in nature (syntax), as defined in a regex spec. In those cases, reporting the "in:" data paths are often more confusing than useful.

For example:

user=> (let [a/b 1] b) CompilerException clojure.lang.ExceptionInfo: Call to clojure.core/let did not conform to spec: In: [0 0] val: a/b fails spec: :clojure.core.specs.alpha/local-name at: [:args :bindings :binding :sym] predicate: simple-symbol? In: [0 0] val: a/b fails spec: :clojure.core.specs.alpha/seq-binding-form at: [:args :bindings :binding :seq] predicate: vector? In: [0 0] val: a/b fails spec: :clojure.core.specs.alpha/map-bindings at: [:args :bindings :binding :map] predicate: coll? In: [0 0] val: a/b fails spec: :clojure.core.specs.alpha/map-special-binding at: [:args :bindings :binding :map] predicate: map?

Here, "In: [0 0]" is not helping me as a user understand the issue (although the data is helpful to error printers like expound). However, if these are nested s/keys specs, the in: data are keywords which provide a lot of information.

Proposed: When printing in the repl, if the explain printer is the default explain printer, remove all of the :in data from the explain-data problems before printing. (But don't do this if a custom printer is being used, like expound.)

user=> (require '[clojure.spec.alpha :as s]) nil user=> (s/explain int? :a) val: :a fails predicate: int? nil user=> (s/explain (s/cat :i int?) [:a]) val: :a fails at: [:i] predicate: int? nil user=> (s/explain (s/map-of keyword? int?) {"hi" 5}) In: ["hi" 0] val: "hi" fails at: [0] predicate: keyword? nil

Patch: clj-2396-3.patch

Environment

None

Attachments

3
  • 05 Sep 2018, 01:11 PM
  • 29 Aug 2018, 03:39 PM
  • 28 Aug 2018, 10:05 PM

Activity

Show:
Completed

Details

Assignee

Reporter

Approval

Ok

Patch

Code

Priority

Affects versions

Fix versions

Created August 28, 2018 at 10:03 PM
Updated September 5, 2018 at 1:20 PM
Resolved September 5, 2018 at 1:20 PM