bors c872a1418a 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		2024-07-03 11:56:36 +00:00
..
check_consts	Instance::resolve -> Instance::try_resolve, and other nits	2024-07-02 17:28:03 -04:00
const_eval	Fix spans	2024-07-02 15:48:48 -04:00
interpret	Auto merge of #125507 - compiler-errors:type-length-limit, r=lcnr	2024-07-03 11:56:36 +00:00
util	rename CompileTimeInterpreter -> CompileTimeMachine, CompileTimeEvalContext -> CompileTimeInterpCx	2024-06-13 20:30:11 +02:00
errors.rs	don't ICE when encountering an extern type field during validation	2024-06-22 17:39:01 +02:00
lib.rs	use is_none_or in some places in the compiler	2024-06-12 16:20:07 +02:00