`:warning-handlers` 目前接受一个函数对象，这是在通过 cljs.main 调用时无法发送的。
为了辅助构建工具，增强这些选项以支持在 1.10 中通过 `requiring-resolve` 接收一个符号。这样，构建工具就可以引用类路径上的函数。
CLJS 可以从
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/server.clj#L263-L270 夺取内容
我相信 :watch-fn 和 :watch-error-fn 已经通过
https://github.com/clojure/clojurescript/blob/47386d7c03e6fc36dc4f0145bd62377802ac1c02/src/main/clojure/cljs/closure.clj#L80-L109 做了正确的事情
h4. 所期望的行为
{{:warning-handlers}} 编译器选项现在能够通过它们的完全限定命名空间符号指定函数。例如，以下 {{cljs.edn}} 的 {{--compile-opts}}
{:warning-handlers [some.namespace/warning-handler1
some.namespace/warning-handler2]}
将找到和解析警告处理函数 {{warning-handler1}} 和 {{warning-handler2}}，只要它们存在并且位于类路径上。
h4. 分析
* 如上所述，我们确实有前期工作用于解决编译器选项：{{:watch-fn}}、{{:watch-error-fn}} 以及 {{:preprocess}}。
* {{:warning-handlers}} 在几个地方绑定到 {{\*cljs-warning-handlers\*}}，但只从其中一个函数：{{cljs.analyzer/warning}} 中使用。
* 前期工作使用私有函数 {{cljs.closure/sym->var}} 来解析。
h4. 方法
将 {{sym->var}} 函数从 {{cljs.closure}} 移到 {{cljs.util}}，使其公开，并使 {{load-mutex}} 成为参数。
从 {{cljs.analyzer/warning}} 使用 {{sym->var}} 解析每个警告处理器。
h4. 测试
向 {{cljs.analyzer-api-tests}} 添加测试以验证成功和符号配置错误的路径。
h4. 实施注意事项
# 不考虑自托管的 ClojureScript
# {{sym->var}} 抛出 {{:compilation}} 阶段异常，我认为这对于警告处理器来说是合适的，因为选择的余地：
https://clojure.org/reference/repl_and_main#_error_printing# {{sym->var}} 将相关编译器选项关键字包含在 {{ex-info}} 的映射中。但是...在 {{cljs.analyzer/warning}} 中，我们正在处理绑定 {{\*cljs-warning-handlers\*}} 而不是编译器选项关键字。我假设在从处理 {{\*cljs-warning-handlers\*}} 的 {{cljs.analyzer/warning}} 中退化的错误中引用 {{:warning-handlers}} 是可接受的。
h4. 观察
关于 `{{sym->var}}` 及其使用，有一些奇特之处：当符号命名空间未找到时抛出异常；当符号未完全限定时也抛出异常。然而，符号未解析的错误却被悄然忽略。这在我看来有点对用户不友好。为此，我在这次变更中引入了 `{{sym->var-checked}}`，当符号未解析时抛出异常。可以考虑在现有调用 `{{sym->var}}` 的地方使用 `{{sym->var-checked}}`，可能需要单独的工单来处理。
因为警告处理器只在 `cljs.analyzer/warning` 中解析，所以用户只有在发生警告时才会意识到配置错误。这可能是利也可能是弊，取决于您的观点。或许提前从可能的路径中重新解析，即使只是为了更快速地失败，也会有所帮助。或许可以从 `cljs.cli/load-edn-opts` 中实现？
