Swift.org blog: New Diagnostic Architecture Overview

[tkremenek (Ted Kremenek)]

There is a new blog post on Swift.org titled "New Diagnostic Architecture Overview" that talks about investments in Swift 5.1and the upcoming Swift 5.2 release to improve the diagnostics from the compiler:

New Diagnostic Architecture Overview

The post is written by @xedin. Please feel free to ask questions about the blog post here!

[cukr]

Omg better error messages! That's so awesome! Right now error messages are the worst part of swift, I'm excited. I hope it will be the end of types called _ in error messages

[owenv (Owen Voorhees)]

@xedin what do you think about adding a copy of this to the compiler's docs/ directory? I think it'd be a really great resource for contributors writing a fix for the first time.

[xedin (Pavel Yaskevich)]

Definitely! I'm working on the version of this to add to the compiler documentation.

[Nevin]

Awesome work @xedin! The blog post is highly informative and I thoroughly enjoyed reading it. I very much look forward to seeing the new diagnostic architecture in action.

I did notice a number of places in the text where small words like “the” were missing, and a few places where extraneous words could be removed, so I took the liberty of doing some proofreading.

Proofreading comments

Note that this is a brief introduction; for more details please refer to [the] compiler’s documentation on the type checker.

Let’s consider [the] following example function

a type variable denoted with $<name> which can assume any type that satisfies [the] constraints associated with it.

After [the] Constraint Generation stage completes, the constraint system for [the] expression str + 1 will have a combination of type variables and constraints.

$Plus represents the type of [the] operator + itself, which is a set of possible overload choices to attempt.

Now [the] applicable to constraint could be tested because $Plus has been bound to a concrete type.

Simplification of [the] ($Str, $One) -> $Result <applicable to> $Plus constraint ends up matching two function types ($Str, $One) -> $Result and (String, String) -> String which proceeds as follows:

At this point [the] only remaining constraints are:

We can see that [the] error location would be determined by the solver as it executes [the] inference algorithm.

Complex expressions could have many more than one such location because existing errors result in new ones as [the] inference algorithm progresses.

To narrow down error locations in situations like that, [the] solver would only pick solutions with the smallest possible number thereof.

[The f]ix for our example is to ignore that String doesn’t conform to [the] ExpressibleByIntegerLiteral protocol.

Such [a] relation combined with type information makes it straightforward to provide tailored diagnostics and fix-its to all of the problems diagnosed via [the] new diagnostic framework.

In our example, it has been determined that [the] type variable $One is an error location, so [the] diagnostic can examine how $One is used in the input expression:

with a note about [the] second argument not conforming to [the] ExpressibleByIntegerLiteral protocol, or the simpler:

[The l]ocation in the source code where the failure came from

[The t]ypes and declarations involved in the failure

The inference algorithm is going to try and match ($X) -> $Result to (inout Int) -> Void, which results in [the] following new constraints:

Previously, this used to be diagnosed as [a] completely unrelated problem:

At this point it’s more or less clear how error locations are identified, but it’s not yet obvious how to help the solver to make forward progress in such scenarios so it can derive a complete solution.

As we have noted before, all of the type variables and constraints carry information about their relationship to the sub-expression they have originated from.

Also, the term “Fix-It” appears in a few places with both the F and I capitalized, and it stuck out as odd though I wasn’t sure if it was intentional.

[xedin (Pavel Yaskevich)]

Thank you very much, @Nevin! I'll get that incorporated as soon as possible!

[strangemonad (Shawn Morel)]

This is absolutely fantastic work.

Would it be possible to document where community members might be able to help porting and improving error diagnostics? I feel like this is one place where the rust community shines.

[xedin (Pavel Yaskevich)]

Yes! I'm preparing changes to documentation which are going to talk about ConstraintFix and FailureDiagnostic interfaces and give examples of how to create a new fix/diagnostic and integrate it into the solver.

[DevAndArtist (Adrian Meister)]

I said it somewhere else, but I find it ironic that the blog post features examples of SwiftUI as it‘s not part of the open source project and was pushed back in the forums by admins a little.

[RayZhao (Ziyuan Zhao)]

Fantastic! The error messages now in SwiftUI really push me over the edge. Looking forward to the update!

[JetForMe (Rick M)]

I find PromiseKit to really tax the type inference engine, so it’d be great if it could do better, but at the very least getting better diagnostics would be a huge help when using it.

[typesanitizer (Varun Gandhi)]

If you're able to do so, please file an issue (or more than one!) with a code example.

Having real world examples where the type inference is struggling is good from the compiler-side as that gives us more realistic test cases and helps evaluate changes to the type checker much better.

[Lantua]

It'd also be nice to have a warning for when type checker is struggle, but not to the point of failure. Like

This statement may take a long time to compile. Consider breaking it into subexpressions.

I remember this being discussed in the forum, but couldn't find where.

[xedin (Pavel Yaskevich)]

@Lantua

This statement may take a long time to compile. Consider breaking it into subexpressions.

We actually attempted to do something like that before, but the hard problem here is way to accurately estimate how much space has been explored and how much remains to be explored.

[Nevin]

@xedin

We actually attempted to do something like that before, but the hard problem here is way to accurately estimate how much space has been explored and how much remains to be explored.

My understanding of Lantua’s suggestion is that, if we have some time limit on type checking that produces an error if an expression goes beyond x seconds, then we could raise a warning for expressions which do type check successfully, but take more than, say, x/2 seconds.

[suyashsrijan]

I think you can use -warn-long-expression-type-checking=<limit> and -warn-long-function-bodies=<limit> frontend flags for that.

[xedin (Pavel Yaskevich)]

There are existing flags for that already as @suyashsrijan points out, but using timers/memory is unreliable and we couldn't find a better algorithmic criteria to estimate how complex the expression is going to be (for now).

[Bruno (Bruno Berisso)]

Thanks for this!

Hope this revival my enthusiasm about Swift because the bad errors were absolutely frustrating. I would prefer to have this instead of SwiftUI or PromiseKit.

I have one question, could we consume these diagnostic information with an API? I'm thinking in an integration with SourceKit for example to suggest smart quick fixes.

Thanks again!

[Bas_Broek]

Thanks for the blog post, Pavel, this was a great read!

[bkocik (Bill Kocik)]

This was a fascinating read - and a reminder that I am not nearly smart enough to write a compiler.

I stumbled into this after spending over 2 hours chasing phantom errors (like "Double cannot be converted to CGFloat") when the real problem was that I missed a $ when passing a binding in a SwiftUI view somewhere else. Very much looking forward to the 5.2 release!