你好，@findleyr,听起来这像是cmd/compile(而不是gopls)。
我昨天发送了https://go.dev/cl/390578来尝试处理一些类似的情况，从快速查看来看，似乎使用any和comparable也可以进行类似的修复。
我可能也会在这里尝试为这个问题提交一个CL,但首先想在这里检查一下，以防万一有什么不合理的地方(例如，基于你在上面的#51270(评论)中提到的内容)。

Hi @thepudds,我认为在types2(即cmd/compile)中进行这种类型的更改是没问题的。出于哲学原因，go/types没有提到go.mod(它是构建系统无关的),但我认为我们已经决定让编译器这样做是可以的。

CC @bcmills@matloob

这个错误来自go/types。@feliixx,你在VS Code(或其他使用gopls的编辑器)中遇到了这个问题吗？
CC @hyangah@suzmue

#48966 与此有一定关联，因为 go 命令可以为不匹配的版本产生更好的错误提示。
#46136 与此非常紧密相关，因为 vet 命令(以及/或 gopls )可以标记使用过于新的标识符—— any 只是恰好是一个特殊的内置标识符。

我的2c:这里的根本问题是编译器和/或类型检查器不能假设一个构建系统，因此通常避免以这种方式具有规范性。话虽如此，cmd/compile/internal/types2确实直接提到了go.mod版本。我选择不在go/types中包含它，这更有可能与没有关联的go.mod文件的包一起使用。
理想情况下，我们会暴露一个错误代码或 Package 错误，以便调用者(go命令或gopls)可以提供规范性建议。我们一直在为go/types计划这个功能，所以在go/types.Error上有一个未导出的字段来保存这样的错误代码。目前我们可以使用这个字段和解析错误字符串的组合(参见#51086)。
附注：实际上，这是一个单一错误代码可能不足以满足需求的好例子。实际错误是“未声明的名称”；一个可能的次要错误是“不支持的功能”(因为“任何”是不支持的),而且以结构化的方式显示这个功能是在哪个版本引入的会更好。
CC @griesemer

@findleyr 我没有使用gopls,只是直接在终端运行go build。