aaron.ballman added a comment. In D135551#3849944 <https://reviews.llvm.org/D135551#3849944>, @inclyc wrote:
>> - Prefer llvm_report_error() in any circumstance under which a code path is >> functionally possible to reach, but only in erroneous executions that >> signify a mistake on the part of the LLVM developer elsewhere in the program. >> - Prefer llvm_unreachable() in any circumstance under which a code path is >> believed to be functionally impossible to reach (even if technically >> possible to reach). The API is now self-documenting to mean "this code >> really should be totally unreachable". > > I think `llvm_unreachable` already has the functionality reporting bugs for > developer in our implementation, with +Assertions by default Yes, in terms of its runtime behavior. So long as we're not making debugging harder for some large group of people, the runtime behavior is not really what I'm concerned by though. I'm focusing more on code reviewers and project newcomers and whether our code is self-documenting or not. Having a policy to use an API that says code is not reachable in situations where that code is very much reachable is the crux of my problem -- the API is sometimes a lie (and a lie with optimization impacts, at that) and we force everyone to pay the cognitive costs associated with that when reading code. If we end up with two APIs that have the same runtime behavior, I'm okay with that. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D135551/new/ https://reviews.llvm.org/D135551 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
