I have seen SR-1795 but I don't think I am doing any overloading like this.

This doesn't happen at all in non-WMO optimized builds? Very strange.

The part of the crash log below the stack trace might have information about what function is causing the problem, but if not, we'd probably need to see your project to be any help.

Yes, it doesn't even happen in Single File Optimization (-O) builds. Only WMO.

Sadly there is no line after the stack trace except for the "Program arguments:..." line, and that only points to said file that is clearly not the culprit.
I found out however that it is always the first file of the target it tries to compile.

The project consists of some frameworks, which build before, and when the main app starts building, the first file always crashes the compiler. I have been starting to remove those files from the target, and it just keeps crashing on the next. Does this tell something?

I can't share the project with you unfortunately as it consist of quite a few other private frameworks.

With my severely limited knowledge of the toolchain - is it correct that the problem is that there are two functions that seem to emit the same mangled name in SIL even if they should be unique?

Does the error mean, that both are functions `(A) -> Void` of some name where A might be different for both functions, but they return the same SIL name anyway?

Just trying to figure out if starting to rename any functions in my project would help or not.

Still happens on the latest `swift-3.1-DEVELOPMENT-SNAPSHOT-2017-01-22-a.xctoolchain`

(I am checking every snapshot because I finally want to enable this again and I saw some SILGen related commits lately 😉 )

That's the general problem, yes, but given that you're only seeing it in WMO mode I doubt that it's actually two functions you have in your project. I would expect you'd get linker errors for anything you wrote explicitly.

Without any code changes this now compiles as of Xcode 8.3 beta!

I cleaned out twice to make sure because I couldn't believe it.
So the fix must be between `swift-3.1-DEVELOPMENT-SNAPSHOT-2017-01-22-a.xctoolchain` and whatever is inside Xcode 8.3 beta.

Any ideas what fixed it?

As of Xcode 8.3 beta.

See comment

IIRC 8.3b1 doesn't have assertions on, so it might just be falling back to some reasonable-ish behavior. I don't think we should treat this as fixed just yet…but at the same time I'm not sure what we can do to help without more information.

I'd be happy to help and experiment, but I cannot send you my project unfortunately.
(Does being restrictive (e.g. `private` and `final`) with types help? Does the mangled name include scope somehow?)

So if I understand correctly, there is nothing wrong with the resulting binary if it compiles, just that SILGen made some assumptions that it shouldn't have made explicitly, but it was luckily right? Or will I experience undefined behavior in my app when I use `-Owholemodule` now?

It really might be undefined behavior. Consider the case where there really were two different functions; it probably just picked one and went on. That wouldn't be correct.

Ok I'm giving up for today (it's close to midnight here).

One thing that came to my mind is that it could be related to Generic subclasses trying to conform to objc protocols. Those also trap the compiler. E.g.

class MyVC<A>: NSViewController {}
extension MyVC: NSTableViewDelegate {}

Those however give a different message.

I do have some generic classes that implement and conform to NSTextFieldDelegate, NSComboBoxDelegate and such, but those never had a problem so far. If this seems like a possibility to you I can try to weed all of those out of my app tomorrow.

BTW, I checked and if I remove all code (except for the AppDelegate) of my macOS App, it indeed does compile. So it shouldn't be one of the included other projects in the workspace.

Curious

Time well spent!

Thank YOU guys for doing the hard work of actually fixing things 😉

BTW, what would I have to do to contribute a test case for such an example to the Swift repo (I do find crashers regularly in my projects)?

I'd love to actually help by providing tests as well, but I am not sure where to start (or if that is even feasible).

In Xcode 8.3 this doesn't crash the compiler anymore, but sourcekit is in perma-crash mode or so, since syntax highlighting is constantly crashing or so.

This brings me back to a question I asked before somewhere but never got an answer: What version of Swift is used for syntax highlighting. In one of my other bugs it was also the case that the compiler didn't crash anymore but the syntax highlighting still couldn't handle the case and constantly crashed.

It's always the same version of Swift as the compiler, unless you're using the for-compiler-testing-only build setting SWIFT_EXEC (or a non-public build setting Xcode people use, which is unlikely). That doesn't mean there are no bugs, though—they clearly go down different code paths since there are many times the compiler crashes and syntax highlighting or code completion does not. As always, we'd need a project to really be sure.

To your earlier question, reduced test cases are very useful. If you want to add them to the compiler test suite, you can follow the instructions to build Swift locally at https://github.com/apple/swift, and then add new tests to the test/ and validation-test/ folders, following the (admittedly skimpy) documentation in docs/Testing.rst. (This shouldn't just be arbitrary code; it should either produce a crash—in which case validation-test/compiler_crashers_2/ is a good place to put the test case—or be something that you don't think is covered by the existing tests.)

Once you've made that change, you can submit a pull request to the main Swift repository with your new test, and one of us will merge it in.

Given your skill at reducing your own issue, another way to contribute would be to look at the open bugs tagged CompilerCrash that have whole projects attached and reduce them, so that whoever gets around to fixing the bug will have an easier time pinpointing the problem.

Thanks Jordan for taking the time to explain!

The test project attached to this SR is a prime example of SourceKit crashing where the compiler is fine though.

I will have a look at the docs and also at reducing other people's examples.

Oops, I forgot there was still a project attached! Can you attach a crash log, too, so that we know what SourceKit was trying to do? (Check Console.app.)

Added a crashlog from Console.app which I believe is related to this now.

Ah, that's still a compiler crash, though, not a SourceKit crash.

Where would I find the sourcekit log?

Mhmm usually I find SourceKit crashes with

ls ~/Library/Logs/DiagnosticReports | grep SourceKitService | wc -l

but this shows 0 at the moment (which is usually in the low hundreds)

They should also be under "User Reports", with the process name "SourceKitService".

Hm, that's where I'd expect them to be. @akyrtzi, any insights?

Seems they have changed location. Because switching between the two files in the project definitely kills source coloring every time but there is no crash report in that directory

AFAIK crashlogs should still go to that directory.
I cannot reproduce any sourcekitd crash with the attached project and Xcode 8.3, do I need to do something specific ? I tried various things.

Mhm, and syntax highlighting works flawlessly for you?

I suspected that it might not be a SourceKit crash but maybe something else related to syntax highlighting. I just always assumed they were the same thing in this context.

Anyway, I don't want to keep you from doing far more important work just because my syntax highlighting doesn't work.
Your time is far too precious for that
(BTW I have submitted a new crasher in the meantime ... wink wink 😛 )

Since the compiler doesn't crash anymore I guess you can close this issue?

Tested again in Xcode 10 and this is definitely fixed