轻松识别已弃用的命名空间/变量

Question

来自邮件列表 http://groups.google.com/group/clojure/msg/c41d909bd58e4534。您可能会在不经意间使用已弃用的命名空间或变量。文档警告很小，并且没有编译警告。

建议：

添加新的 {{\*warn-on-deprecated*}} 动态变量，默认为 false
当加载 {{{:deprecated true}}} 命名空间时，向 stderr 输出警告。
当分析 {{{:deprecated true}}} 变量时，向 stderr 输出警告。
当展开 {{{:deprecated true}}} 宏时，向 stderr 输出警告。
新的系统属性 clojure.compiler.warn-on-deprecated
使用 clojure.compiler.warn-on-deprecated 编译 Clojure 本身
修复 Clojure 内部的弃用警告（replicate, clear-agent-errors）
使用 :deprecation 标签标记 clojure.parallel 为已弃用

示例


(set! *warn-on-deprecated* true)

;; 使用了已弃用的变量（在编译时）
(defn ^:deprecated f [x] x)
(f 5)
;;=> 弃用警告，NO_SOURCE_PATH:7:1 : var #'user/f is deprecated

;; 使用了已弃用的宏（在宏展开时）
(defmacro ^:deprecated m [x] x)
(m 5)
;;=> 弃用警告，NO_SOURCE_PATH:7:1 : macro #'user/m is deprecated

;; 在加载了已弃用的命名空间（在加载时）
(ns foo {:deprecated "1.1"})
(ns bar (:require foo))
;;=> 弃用警告：从命名空间 `bar` 加载了已弃用的命名空间 `foo`


补丁：706-deprecated-ns-var-warnings-tested-3.diff

问题：弃用警告的默认值应该是 true 吗？进行升级的用户可能会看到新的警告，可能会感到惊讶。

应该在弃用上发出警告，还是不发出警告？

Answer 1

评论由：richhickey

我不介意将警告信息输出到stderr

Answer 2

评论由：lvanderhart

706-deprecated-var-warning.diff 在使用已废弃的变量时会添加警告。其他三个补丁清理了废弃警告。

Answer 3

评论由：jafingerhut

非常好的内容。我查看了第一个补丁，但没有看到任何能让某人通过命令行禁用废弃警告的选项，就像今天可以将warn-on-reflection设置为true一样。

对于废弃警告来说，这很重要吗？

Answer 4

评论由：jafingerhut

我希望能快速简单地添加源文件、行和列信息到废弃警告信息中。但这并不像添加到format()调用中那样简单，因为analyzeSymbol方法不接收这些值作为参数。这个废弃检查是在一个很难将其与源文件、行和列关联的地方进行的吗？是否可以在容易获取这些信息的地方进行？

Answer 5

评论由：gshayban

另一个补丁——这次是在加载废弃命名空间时发出警告，而不是变量。这个补丁需要第一个补丁。

关于行/列：如果需要，我会弄清楚如何将编译上下文传递过去。

关于编译标志：我也有一个补丁，但我还在验证如何使用。warn-on-reflection是如何通过命令行设置的？

Answer 6

评论由：jafingerhut

关于编译标志。如果你希望实现这个标志，可以不推迟，但了解一下其他人是否希望这样的命令行选项可能是值得的。我提出这个问题的目的是希望得到这样的反馈。

关于Clojure编译器中处理方式，请在Compile.java中搜索REFLECTION_WARNING_PROP和相关代码。如果你直接通过Java命令行调用Clojure编译器，请使用-Dclojure.compile.warn-on-reflection=true（默认为false）。如果你想通过ant或Maven进行操作，请查看最近发送到Clojure Dev Google组的相关电子邮件链。链接：[https://mail.google.com/mail/?shva=1#label/clojure-dev/13aa0e34530196c3](https://mail.google.com/mail/?shva=1#label/clojure-dev/13aa0e34530196c3)

还有一个名为compiler-options的单独命令行标志（参见Compile.java），它作为编译器内部的map实现。它比warn-on-reflection添加得更晚，可能是添加更多此类选项的首选方法，以避免在其他地方继续添加更多pushThreadBindings调用参数。

Answer 7

评论由：gshayban

谢谢，Andy。

对于最后的ns补丁，与调用(print-method msg err)等价，而不是将out绑定到err，可能更易读。如果这更受欢迎，我会很高兴发送它。

Answer 8

评论由：jafingerhut

2013年2月12日发布的706-deprecated-var-warning-patch-v2.txt与2012年10月26日发布的706-deprecated-var-warning.diff相同，但可以干净地应用到最新master版本。

Answer 9

评论由：jafingerhut

对于任何希望使用此功能但目前正在审查此票据的人，Eastwood lint工具报告了对已弃用的Clojure函数和Java方法的调用。[https://github.com/jonase/eastwood](https://github.com/jonase/eastwood)

Answer 10

评论者：alexmiller

我对将这考虑为Clojure 1.9的性能很感兴趣，但我需要一些帮助来准备它。我对当前状态的一些评论：- 票需要更多关于当前方法的具体细节

• 我更喜欢使用}而不是{}，因为它与用于标记弃用变量的关键字相符
• 警告信息没有提供位置信息，这很糟糕 - 应该类似于反射消息
• 需要测试 - 请参考 test/clojure/test_clojure/compilation.clj 和 test/clojure/test_helper.clj 中的示例（should-not-reflect）
• Clojure 自身也存在一些已弃用使用情况的实例 - 如果能在补丁中清理这些情况将会很不错。这可能需要单独的补丁，取决于是否容易修复。如果测试/中存在实际上可以留存的案例，可以在该命名空间中将 * } 设置为 false。
• 当前的默认设置是 true - 恐怕应该改为 false 才能与反射警告的默认设置相匹配。

Answer 11

由：vijaykiran 评论

(链接：~alexmiller) 我可以试一试。

Answer 12

评论者：alexmiller

嗨，Vijay，Andrew Rosa 已将此问题分配给自己，请与他协调，因为他已经开始着手解决这个问题了。

Answer 13

由：bozhidar 评论

仅一点小意见 - 默认启用弃用警告不是更常见吗？可以说，弃用警告比反射警告更重要，因为你的代码未来可能会因为未注意到使用了弃用功能而被破坏。

Answer 14

评论者：alexmiller

(链接：~bozhidar) 我还在犹豫。我对将其设置为默认值的主要犹豫是人们可能会突然出现大量新警告（这可能有好有坏）。这取决于我们希望人们多么关注弃用情况。

Answer 15

由：pbwolf 评论

默认关闭的弃用警告没有解决本票据给出的首要问题：“在使用弃用命名空间时，容易不知不觉地这样做。”

这与反射警告不同。你可以随时关注速度，随心所欲。但是，最终删除有害功能的突然，不愉快的情况将是一个有用的警告。

但是——假设我写了300行Clojure代码，并使用了来自jar文件的一百万行代码。我的代码中是否存在已弃用的警告会被那些jar文件中的警告所淹没吗？更糟糕的是，这场海啸可能会持续数周或数月，直到库的相应作者赶上。由于那些jar文件由'lein ancient'和类似的工具（更有效率地）覆盖，我宁愿限制弃用警告只针对我的代码，也许可以通过命名空间前缀来限制，如果从编译器的角度来看，从jar文件中来或不是不方便。