Semi-recent changes for the solver-memory-threshold flag

Using -warn-long-function-bodies to limit compile times is complex as our development machines and CI machines have very different performance characteristics. Also, having a large codebase with warnings-as-errors makes it more complex.

I’ve used the -solver-memory-threshold instead of our (very large) codebase as some rough way of limiting the complexity of expressions and forcing engineers to annotate types in some of the more complex, chained closures.

After moving to Swift 4.1, this limit seems to not matter very much. It looks like it’s most likely due to this patch : https://github.com/apple/swift/commit/5f2aeec434007fb46729506a3835c19bb9aa3c41

I don’t have a debug version of the compiler, but I would guess that we’re no longer hitting the memory limit for complex experssions in our codebase due to this early exit clause:

// If we haven't explored a relatively large number of possibilities
// yet, continue.
if (CountScopes <= 16 * 1024)
    return false; 

Would it make sense to move the memory check at the bottom of getExpressionTooComplex() up a little so that we’re still honoring the limit being requested by the user ?

1 Like

/cc @rudkx @xedin

@rudro Could you please create an issue at bugs.swift.org for this? We are still trying to figure out what the best “too complex” metric is, so it would be great to track problems associated with current logic.

@xedin Sure : https://bugs.swift.org/browse/SR-7525