欢迎！请查看关于页面以获取更多关于这个工作方式的信息。
对于从TANAL衍生出的静态分析工具来说，确定一个符号是用户定义的还是代码生成的结果经常是很有用的。作为分析工具依赖于Clojure核心进行评估和符号生成，因此想要对生成的符号进行注释的用户必须提供替换clojure.core/gensym的绑定，该绑定与以下补丁片段等价。这种重载对于TANAL、TE*或用户代码来说不合适，因为它是对clojure.core行为的重定义，这种行为应该是标准的而不是用撬棍对待的用户。
由：gtrak发表的评论
这最终可能有助于过滤出自reify在CLJS中定义的符号，如't131045'。我一直在autodoc-cljs的概念验证中看到这种行为，这最终可能会瞄准tools.analyzer。
由：alexmiller发表的评论
关于补丁，为什么不调用接受元数据的Symbol构造函数，而不是使用with-meta？出于性能考虑，最好也使用同一个常量映射。
由：arrdem发表的评论
因为编译器会将元数据映射作为一个静态字段发出，补丁的现状将使得所有注释的符号共享同一个映射实例。调用元数据构造函数是合理的，我会更新补丁。
因此，Symbol的元数据构造函数是私有的，详见https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Symbol.java#L100。如果不直接更改，就无法从核心库中构建带有元数据的符号。如果您担心通过with-meta添加元数据的间接作用导致var开销，可以使用with-meta进行内联，但我们这样做是没有理由的。暴露当前私有元数据构造函数可能是正确的修复方案，尽管这只是个独立的工单。
评论由：jafingerhut
根据上述评论，这个补丁似乎不是最终版本，但仅供参考，我发现的一个自动脚本可以干净地应用到2014年6月9日补丁0001-Annotate-generated-symbols-with-metadata.patch，但是Clojure无法构建。
谢谢Andy，我将在早上重新设计并测试它
由于clojure.lang.Symbol/intern的工作原理，直接暴露和访问元数据构造函数没有意义。更新后的补丁直接调用clojure.lang.Symbol/withMeta，而不是通过clojure.core/with-meta间接调用，也不会受到调用Var时的性能损失。在我的系统上可以干净地构建。
Reid，虽然JIRA可以处理具有相同名称的多个附件，但对于人和某些脚本来说，这可能会有些混乱，用于确定哪些补丁可以应用并且可以干净地测试。您愿意将您的补丁之一重命名吗？
对这个补丁的第三次也是最后一次更新。
