IFNDR是否优先于可诊断规则违规？混合违规的编译器诊断要求探讨

[intro.compliance.general]/2 规定了编译器处理输入程序的规则，针对格式不良的程序有两项核心要求：

• (2.2) 编译器对违反可诊断规则的情况，必须至少输出一条诊断信息
• (2.3) 对于违反无需诊断规则的程序，编译器不受任何约束

但该段落并未明确这两项要求的优先级：如果程序同时存在违反可诊断规则（需输出诊断）和违反无需诊断规则的情况，编译器是否仍必须输出诊断信息？

示例1：混合IFNDR与可诊断违规 #

// 格式不良，需输出诊断
int main() { using T = void&;; }

// 依据[temp.res.general]/8.1和[temp.res.general]/8.4属于IFNDR（无需诊断的格式不良）
void f(auto) { using T = void&;; }

示例2：混合运行时UB与可诊断违规 #

如果IFNDR的优先级逻辑延伸到运行时未定义行为（UB）场景，类似下面的程序也会引发疑问：

// 始终触发运行时未定义行为
int main() { return *(int*)0; }

// 格式不良，需输出诊断
using T = void&;;

从标准的技术层面来看，这类同时包含两种违规的完整单翻译单元程序，编译器是否可以不输出诊断信息？

从实现质量的角度，编译器应该尽可能在这类场景下输出诊断信息，但标准并未强制要求这么做——这一结论和过往的资料、共识一致。比如[temp.res.general]/8.1中的限定语“且模板未被实例化”如果没有优先级逻辑就毫无意义，但标准在其他场景（如[dcl.constexpr]/6）却没有使用这类必要的反向限定语。

内容的提问来源于stack exchange，提问作者user17732522