diff options
| author | Matthias Krüger <476013+matthiaskrgr@users.noreply.github.com> | 2025-06-13 05:19:16 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-06-13 05:19:16 +0200 |
| commit | 6a09b67bdc67a4d8345baec04338db52079002cf (patch) | |
| tree | 9962b827ecd8bc2febc4256d8e572c27449244ab /compiler/rustc_codegen_llvm/src/common.rs | |
| parent | f6b02bbfa3405675021424a92096fd1f3dd57bf2 (diff) | |
| parent | dd78c95c54a0850571ec6ed82da2f8bb888de545 (diff) | |
| download | rust-6a09b67bdc67a4d8345baec04338db52079002cf.tar.gz rust-6a09b67bdc67a4d8345baec04338db52079002cf.zip | |
Rollup merge of #142267 - workingjubilee:debug-assert-less-in-ast-lowering, r=oli-obk
assert more in release in `rustc_ast_lowering` My understanding of the compiler's architecture is that in the `ast_lowering` crate, we are constructing the HIR as a one-time thing per crate. This is after tokenizing, parsing, resolution, expansion, possible reparsing, reresolution, reexpansion, and so on. In other words, there are many reasons that perf-focused PRs spend a lot of time touching `rustc_parse`, `rustc_expand`, `rustc_ast`, and then `rustc_hir` and "onwards", but `ast_lowering` is a little bit of an odd duck. In this crate, we have a number of debug assertions. Some are clearly expensive checks that seem like they are prohibitive to run in actual optimized compiler builds, but then there are a number that are simple asserts on integer equalities, `is_empty`, or the like. I believe we should do some of them even in release builds, because the correctness gain is worth the performance cost: almost zero.
Diffstat (limited to 'compiler/rustc_codegen_llvm/src/common.rs')
0 files changed, 0 insertions, 0 deletions
