diff options
| author | bors <bors@rust-lang.org> | 2024-07-03 11:56:36 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2024-07-03 11:56:36 +0000 |
| commit | c872a1418a4be3ea84a8d5232238b60d35339ba9 (patch) | |
| tree | 65ae1341ed39fcd9b85f95d682ef5710d0b2214f /compiler/rustc_mir_transform/src/coverage/mappings.rs | |
| parent | 2db4ff40af2b9f93b6240dbd67ed7f2f34b19776 (diff) | |
| parent | b1059ccda210e11c19b3c639a13ddd64de781daf (diff) | |
| download | rust-c872a1418a4be3ea84a8d5232238b60d35339ba9.tar.gz rust-c872a1418a4be3ea84a8d5232238b60d35339ba9.zip | |
Auto merge of #125507 - compiler-errors:type-length-limit, r=lcnr
Re-implement a type-size based limit r? lcnr This PR reintroduces the type length limit added in #37789, which was accidentally made practically useless by the caching changes to `Ty::walk` in #72412, which caused the `walk` function to no longer walk over identical elements. Hitting this length limit is not fatal unless we are in codegen -- so it shouldn't affect passes like the mir inliner which creates potentially very large types (which we observed, for example, when the new trait solver compiles `itertools` in `--release` mode). This also increases the type length limit from `1048576 == 2 ** 20` to `2 ** 24`, which covers all of the code that can be reached with craterbot-check. Individual crates can increase the length limit further if desired. Perf regression is mild and I think we should accept it -- reinstating this limit is important for the new trait solver and to make sure we don't accidentally hit more type-size related regressions in the future. Fixes #125460
Diffstat (limited to 'compiler/rustc_mir_transform/src/coverage/mappings.rs')
0 files changed, 0 insertions, 0 deletions
