Swift.org blog: New Diagnostic Architecture Overview

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:

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

57 Likes

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

1 Like

@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.

4 Likes

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

10 Likes

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

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.

5 Likes

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

2 Likes

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.

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.

4 Likes

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. :sweat_smile:

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

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.

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.

1 Like

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.

1 Like

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.

4 Likes

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.

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

1 Like

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).

1 Like

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!

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

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!

1 Like
Terms of Service

Privacy Policy

Cookie Policy