在编译时，具体化对象不满足协议

Question

https://github.com/MichaelBlume/reify-fail

`
(defprotocol Foo
(hello [this] "Says hello"))

(def bar
((reify Foo

(hello [this] "hello, world")))

((when-not (satisfies? Foo bar)
((throw (Exception. "bar doesn't satisfy Foo")))
`

备注

项目是 AOT
另一个命名空间需要这个命名空间。该命名空间先编译。没有该命名空间问题就会消失。

Answer 1

评论者：hiredman

检查代码库后，您采取了哪些步骤来重现此问题？

我克隆了代码库，并运行了lein compile，但没有出现任何错误。

Answer 2

评论者：michaelblume

我使用lein check重现了问题，但lein compile也对我失败了，所以我感到困惑。

Answer 3

评论者：michaelblume

我认为重要的是几乎为空的命名空间应该先编译，可能存在平台在编译顺序上的差异？

Answer 4

评论者：michaelblume

在Mac OS和Ubuntu上，我测试的仓库均失败，两者都使用了Java 8

Answer 5

评论者：michaelblume

在Ubuntu上，我有

$ lein -v
Leiningen 2.7.1 on Java 1.8.0_151 OpenJDK 64-Bit Server VM

Answer 6

评论者：jafingerhut_

在这两个操作系统上：Ubuntu 16.04.3 Linux，macOS 10.12.6

在使用这两个版本的Leiningen：2.7.1，2.8.1

我认为所有实验都使用了一个近期版本的JDK 1.8

在以下Clojure版本中：1.7.0 1.8.0 1.9.0

在使用项目https://github.com/MichaelBlume/reify-fail,的 'lein check' 和 'lein compile' 命令时都会出现错误，但只有在我先执行 '/bin/rm -fr target'（或者在一个目标目录尚未创建的情况下运行它，例如在运行了 'git clone' 命令之后立即运行）后才会出现这种情况。

如果连续运行该命令两次，第一次命令会在目标目录中创建很多 .class 文件，第二次则不会出现错误。

Answer 7

评论者：hiredman

如果我将 :aot :all 替换为 :aot (link: com.lendup.citadel.pipeline com.lendup.citadel.providers.mocky)，我就能复现这个错误。我怀疑lein可以通过在编译命名空间之间执行过时检查来修复这个问题，以避免重复编译传递命名空间。

Answer 8

评论者：hiredman

可能与 https://github.com/technomancy/leiningen/issues/2316 相关

Answer 9

评论者：ikitommi

相关：https://github.com/technomancy/leiningen/issues/2508。

Answer 10

评论者：bronsa

这是Clojure还是Lein问题？我们能用纯clj重现这个问题吗？

Answer 11

评论者：alexmiller

我怀疑可以通过编译特定的顺序来重现这个问题，但我还没有尝试过。但可能的答案可能是：按照正确的顺序编译。

Answer 12

参考：https://clojure.atlassian.net/browse/CLJ-2303（由michaelblume报告）