Reword the "expression too complex" error not to blame the user.

[jckarter]

It's not you, it's us. We shouldn't tell the user their code is too complex, and "solve" doesn't mean anything to them in this context. Make it clearer this is an implementation limitation.

[jckarter]

@swift-ci Please smoke test

[jckarter]

@jrose-apple How does this sound to you?

[kdawgwilk]

the compiler is seems redundant since we know the message is coming from the compiler. unable to typecheck... seems concise and gets the message across

[xwu]

A classic error though; I'll miss its capricious appearances.

[jckarter]

@xwu Well, it's still on us to eventually make this error completely unnecessary…

[langford]

Good fix. In a moment of frustration, anything to help defuse the issue of what is going on is helpful to get the user out of anger mode and back into problem solving mode.

Beyond overall just working on making the compiler able to handle complexity, specific user-achievable fixes would be appreciated.

This is especially true for people without CS degrees and for people whom Swift is just one of many languages they have to do their job in. Sometimes, the issue is they don't understand parsing well enough to begin to fix this error, so randomly go around changing things trying to make it work.

More information or tooling on specific solutions would go a long way. Here are some rough examples you might use to do this.

• Line 56: The number of inferred types in this {closure/declaration/generic function} results in (1,329,223 combinations). The current limit of swiftc is roughly 64,000 combinations. Annotating all of the following expressions with explicit types would cut down the number of combinations to a level likely less than the current limit:
  -Line 56:84: (180 * another_number) + a_number * a_possible_float
  -Line 53:6: let a_number = a_generic_function()

• Line 56: This line requires more combinations of possible types than the compiler currently will perform. Use swiftc --annotate-holes to add placeholders to the file for user-specified types to make the line understandable to the compiler.

• Line 56: The expression is inferring 12 types. Please specify 3 or more of them. Use swiftc --breakup-complex-expressions to breakup the expression into subexpressions which you can manually type to get past this error.

• Line 56: The expression is inferring 12 types. Please rewrite the expression in more lines with more explicit types. <click to expand for example>.

[jrose-apple]

If I'm grammar-nitpicking, I'd say I'd prefer the past tense of the original ("was" instead of "is"), and the second "the expression" should just be "it" ("try breaking it up…").

Per @kdawgwilk's comment, I actually like having "the compiler" in there, even if it is redundant and makes the message longer. It underscores the part you're trying to get across, that it's not an inherent limitation of the language.

I like the idea behind @langford's further improvements but I think that can be separate PRs, and probably needs more help from @xedin and @rudkx.

[jckarter]

@jrose-apple The antecedent to "it" feels ambiguous to me in that case; does it mean "the compiler" or "the expression"?

[jrose-apple]

*shrug* That's fair. For me "sub-expressions" is a strong enough indicator that the "it" refers to the expression.

[gparker42]

This broke in CI. You missed a bunch of tests in validation-test/Sema/type_checker_perf/slow/.

[jckarter]

Thanks Greg, #14509 should sort that out.

[jrose-apple]

Ah, it's cause they're marked long_test. Those don't get run in PR testing by default, I believe.

[rudkx]

The issue is that the scale tests run in PR testing, but the tests that use an actual timer only run for release/no-asserts build, and those don't run in PR testing.

It might not be the right tradeoff, but at the time we felt like some testing of these tests (which we weren't able to fit into the scale-test model) were better than none.