SourceKit crash on L10N autocompletes

[AndrewSB]

This always happens whenever I try to autocomplete the enum in tr(.).

Has anyone found a workaround that gives me all the enum cases so one doesn't have to guess names?

[AliSoftware]

1. What Xcode version are you using ? Seems more of a SourceKit/ Xcode issue to me.

They improved quite a lot autocompletion in the latest versions so please try against those, and if the problem still persist, definitely file an issue on bugs.swift.org and post the link to the issue here.

2. Also, what SwiftGen template are you using? The default one or a custom one?

3. Did you try by using a different --enumName (other than the default L10n one) when generating?

4. As to a workaround until Apple fixes that crash, did you try using the full enum name, like tr(L10n.Foo) instead of just tr(.Foo)? That might help prevent SourceKit from crashing. So typing tr(L10n.⇥ should list you all the enum cases in Xcode's autocompletion list. That's what I usually use personally.

[AndrewSB]

1. 7.3.1
2. default
3. I did not, should I? Do you think that might fix it?
4. tr(L10n.⇥ works!!!, I'll use this for now.

@AliSoftware do you then leave the entire L10n.Foo in tr(), or do you later delete L10n, just leaving .Foo?

[AliSoftware]

3. I don't know, as I don't work on SourceKit and I don't know why it crashes in such occasions (that's why I suggested filing a JIRA in https://bugs.swift.org so we call follow what the Swift compiler folks think about it in the open 😉 ). But I thought it was worth a try, to narrow the cause a bit more

4. Sometimes I do keep the L10n prefix, sometimes I don't. I most cases I delete it because I like conciseness, but sometimes I forget, have no clean rule about this.

Anyway as far as I remember, I don't think I've ever experienced SourceKit crashing on that particular case, I've seen autocompletion sometimes not work when typing tr(.⇥ — like just not displaying any viable suggestion — but not SourceKit crashing (e.g. syntax highlighting was still working).
So not sure but maybe that bug is specific to some external factors, like the fact that you may have more localizable strings that I do in my projects so your enum L10n might have more case in it, or have a number of case that makes SourceKit crash for that specific case, idk. We'll have to let the Swift team investigate by letting them know about that crash 😉

[AndrewSB]

I might be misunderstanding what "SourceKit crashing is". Here's an example of what might happen after I tr(.⇥:

Is that in-fact a SourceKit crash?
It's strange that I almost always face it while you haven't... I wonder why that is.
If it is indeed a source kit crash, I'll go ahead and file a swift compiler bug.

[AliSoftware]

Yeah, what your screenshot shows is indeed a SourceKit crash, with the explicit banner on top (and loss of syntax highlighting because SourceKit crashes).

But I confirm that I never had those just by trying to use autocomplete (like tr(.⇥) — I had some SourceKit crashes in some projects like everybody else, especially on previous versions of Xcode, but never had those just by trying to autocomplete tr(. in Xcode 7.3.1 like you seem to have. That's very strange indeed.

• Is the crash systematic, and especially no matter how many strings you have in your Localizable.strings (so no matter how many case SwiftGen generates in the enum L10n?
• Are you using the latest version of SwiftGen (and more especially the latest version of the default template)? I know some older versions of the template triggered SourceKit crashes and I had to alter them a bit to workaround those SourceKit bugs until they're fixed, so maybe that's just an old one you use without realizing?

See also Apple bugs reported in #56, #57, #112 about those templates which made the compiler crash on optimized builds — they are not the same issue, as they are related to an issue in the Swift compiler writing bad code on some occasions in optimized builds, not about SourceKitService crashing… but maybe you can find interesting info and existing bug reports in there.

Please let us know the JIRA bug number once you've filed it, I can maybe try to push it forward to the Swift compiler team to have their feedback on such bugs. Hopefully if we file such bug report soon enough it could be fixed in next Xcode 8 betas before the GM.

Don't forget to check if you still got the SourceKit crash in Xcode 8 latest betas though before filing a bug to Apple, as maybe they already fixed that crash in SourceKit 😉