Skip to content

check_type_length_limit is broken #125460

Closed
@lcnr

Description

The function was added to prevent hangs during codegen if there are infinite expansions which result in exponential blowup. It does that by computing an estimate of the complexity of the type and checking whether it's above a limit:

fn check_type_length_limit<'tcx>(tcx: TyCtxt<'tcx>, instance: Instance<'tcx>) {
let type_length = instance
.args
.iter()
.flat_map(|arg| arg.walk())
.filter(|arg| match arg.unpack() {
GenericArgKind::Type(_) | GenericArgKind::Const(_) => true,
GenericArgKind::Lifetime(_) => false,
})
.count();

This worked quite well, until we changed the walk to use caching in #72412. It looks like nobody noticed its effect on the type length limit in this PR.

With this the type length estimate grows linearly while the "true" size of the type is still exponential, causing the limit to never be reached in the cases it's intended for. The only remaining test which hits the limit arbitrarily sets it to 8 and uses a linearly recursive type:

#![type_length_limit="8"]
macro_rules! link {
($id:ident, $t:ty) => {
pub type $id = ($t, $t, $t);
}
}
link! { A1, B1 }
link! { B1, C1 }
link! { C1, D1 }
link! { D1, E1 }
link! { E1, A }
link! { A, B }
link! { B, C }
link! { C, D }
link! { D, E }
link! { E, F }
link! { F, G<Option<i32>, Option<i32>> }
pub struct G<T, K>(std::marker::PhantomData::<(T, K)>);

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.P-mediumMedium priorityT-typesRelevant to the types team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions