iOS 8.3 crashes when installing constraints on views that are not in the view hierarchy

[philipengberg]

It crashes with the following exception:

+[NSLayoutConstraint constraintWithItem:attribute:relatedBy:toItem:attribute:multiplier:constant:]: 
A multiplier of 0 or a nil second item together with a location for the first attribute creates 
an illegal constraint of a location equal to a constant. Location attributes must be specified in 
pairs.

This is the stack trace:

3  Foundation    0x0000000184a05ecc VerifyConstraintArguments + 220
4  Foundation    0x000000018488dad0 +[NSLayoutConstraint constraintWithItem:attribute:relatedBy:toItem:attribute:multiplier:constant:] + 440
5  App           0x000000010049c348 -[MASViewConstraint install] (MASViewConstraint.m:291)
6  App           0x0000000100499fdc -[MASConstraintMaker install] (MASConstraintMaker.m:45)
7  App           0x000000010049e0e8 -[UIView(MASAdditions) mas_updateConstraints:] (View+MASAdditions.m:26)

As the title says, this only happens for views that have not been added to the view hierarchy.

Masonry version (0.6.1)

[cloudkite]

@philipengberg you cannot specify constraints on views that are not in the view hierarchy. This is an Auto Layout restriction not a Masonry restriction

[AdamShare]

@cloudkite I think this issue should be reconsidered.

Although clearly a layout constraint crash, Masonry seems to abstract away any references to the view's superview that would otherwise be required with normal relative constraint building.

Making constraints initially is pretty straight forward and this crash actually can be helpful during development to catch issues.

However in more complex scenarios the mas_updateConstraints, or mas_remakeConstraints leave open the possibility of a condition where constraints updates will sometimes get called after a view has been removed from it's superview causing this crash. These crashes can go undetected during development.

Instead of wrapping all these constraint updates in an if statement to check for superviews, we could easily handle these cases internally by logging/asserting the error and ignore an update/remake if the constraints will fail due to superview (second constraint) being nil.

if (!self.firstViewAttribute.isSizeAttribute && !self.secondViewAttribute) {
    secondLayoutItem = self.firstViewAttribute.view.superview;
    secondLayoutAttribute = firstLayoutAttribute;

    if (!secondLayoutItem) {
        // Don't continue to crash. NSLog/NSAssert
        return;
    }
}