`: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}} 作为参数。
利用 {{sym->var}} 从 {{cljs.analyzer/warning}} 解析每个警告处理器。
h4. 测试
向 {{cljs.analyzer-api-tests}} 添加测试，以验证成功和符号配置错误路径。
h4. 实施说明
# 不考虑使用自托管的 ClojureScript
# {{sym->var}} 抛出 {{:compilation}} 阶段异常，我认为这对于 warning-handlers 来说是合适的，给定选项：[a href="https://clojure.org/reference/repl_and_main#_error_printing" rel="nofollow" target="_blank">https://clojure.org/reference/repl_and_main#_error_printing
# {{sym->var}} 包含关联的编译器选项关键字在 {{ex-info}} 的映射中。但是...在 {{cljs.analyzer/warning}} 中，我们正在处理 {{\*cljs-warning-handlers\*}} 的绑定，而不是编译器选项关键字。我假设在处理 {{\*cljs-warning-handlers\*}} 而不是 {{:warning-handlers}} 的错误中的错误中引用 {{:warning-handlers}} 是可接受的。
h4. 观察
# {{sym->var}} 和其使用有点奇怪，因为当 sym ns 未找到时会抛出，当 sym 不是完全限定时会抛出，但对符号未解析的错误则沉默地忽略。这似乎对用户有点残忍。为此更改，我引入并使用了 {{sym->var-checked}} 以在 sym 未解析时抛出。可能需要单独的票据使用 {{sym->var-checked}} 替换现有对 {{sym->var}} 的调用。
由于警告处理器只在实际发生警告时才在 {{cljs.analyzer/warning}} 中解决，因此用户在出现警告之前无法知道配置错误。这可能是正面或负面因素，取决于您看问题的角度。也许在可能路径上更早重复解决，即使只是为了更快失败，也可能是有帮助的。也许可以从 {{cljs.cli/load-edn-opts}} 中开始？
