Skip to content

ConstGoto can produce invalid control flow in cleanup blocks #107315

Closed
@saethlin

Description

@saethlin

With #106613, the crate fallible_iterator doesn't pass MIR validation after ConstGoto (this is why CI on that PR doesn't pass):

error: internal compiler error: broken MIR in Item(WithOptConstParam { did: DefId(0:415 ~ fallible_iterator[87b6]::{impl#25}::try_fold), const_param_did: None }) (after pass ConstGoto) at bb15[0]:
                                Cleanup control flow violation: The blocks dominated by bb15 have edges to both bb14 and bb10
    --> src/lib.rs:1814:5
     |
1814 |     }
     |     ^

This is the validation check that was improved in #106612

To reproduce, build fallible_iterator 0.2.0 with that PR, and using -Zvalidate-mir and --release.

I think the bug here is that ConstGoto is capable of turning MIR that passes validation into MIR that doesn't. It is of course tempting to blame the new pass, but if I recall correctly @JakobDegen previously indicated to me that it seems more likely that a pass which changes the control flow graph is the actual problem here.

I haven't minimized the code pattern that causes the problematic transformation, but I'm including the MIR graphviz dumps of the problematic function before and after ConstGoto:

ConstGoto.before
ConstGoto.after

@rustbot label +A-mir-opt +C-bug

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-mir-optArea: MIR optimizationsC-bugCategory: This is a bug.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions