错误消息中功能名称后缀混淆

Question

某些核心功能名称在错误消息中报告时带有奇特的混淆后缀。

例如，在给{{inc}}、{{assoc}}和{{dissoc}}传递错误数量的参数时，每个错误消息都以不同的方式报告功能名称


clj -Srepro -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.10.0-beta4"}}}'



user=> (inc)
在编译inc时出现语法错误（1:1）。
给：clojure.core/inc--inliner--5436传递了错误的参数数量（0）
user=> (assoc)
评估错误（ArityException）在clojure.lang.AFn.throwArity (AFn.java:429)处。
给：clojure.core/assoc--5316传递了错误的参数数量（0）
user=> (dissoc)
评估错误（ArityException）在clojure.lang.AFn.throwArity (AFn.java:429)处。
给：clojure.core/dissoc传递了错误的参数数量（0）


从用户的角度看，这种行为是没有动机且令人困惑的。也许这些名称应该进一步去混淆并打印时不带后缀。

Answer 1

评论者：alexmiller

这里第一个是一个内联函数，发生在编译期间，所以与其它不同。因为它内联，所以是不可 specs的。名称的组成部分是由编译器生成的。根据名称构造的规律性，这可能是有修复可能的，尽管我认为这并不特别重要。

后面两个一旦应用CLJ-2420将会有点不同

user=> (assoc) 执行错误（ArityException）在user$eval154/invokeStatic (REPL:1)。给：clojure.core/assoc--5406传递了错误的参数数量（0）

user=> (dissoc) 执行错误（ArityException）在user$eval156/invokeStatic (REPL:1)。给：clojure.core/dissoc传递了错误的参数数量（0）

我猜在这两种情况下，你所看到的数字都是Clojure中普遍使用的一种标准技术，所以问题可能在于是否有可能以系统化的方式解决它。当前函数并不携带其未经处理的名称，因此从类名中解密（demunging）永远不可能是一个万无一失的机制。

思考如何做得更好是值得的，但这不是我在近期内打算查看的问题。

Answer 2

参考：[CLJ-2422](https://clojure.atlassian.net/browse/CLJ-2422)（由glts报告）