[SR-4716] Better diagnostics for multifile executable without a main.swift file

[huonw]

Previous ID	SR-4716
Radar	None
Original Reporter	@huonw
Type	Improvement
Status	In Progress
Resolution

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Improvement, DiagnosticsQoI, Driver, StarterBug
Assignee	None
Priority	Medium

md5: 107a386ff1ef4614f95e66bc776c43f4

Issue Description:

$ touch file1.swift file2.swift
$ swiftc file1.swift file2.swift
Undefined symbols for architecture x86_64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)

The problem here is neither file is called main.swift, so the top-level-code `main` function doesn't get emitted. The compiler should check the file names and emit an error rather than going all the way through compilation to hit the link error.

[belkadan]

This applies whenever the driver is in -emit-executable mode (the default), and should probably only kick in if all the inputs are Swift files (so that if someone passes a .o file or a .a file that contains a 'main' it works).

[WFT]

I'm a complete beginner when it comes to contributing code to the Swift project, but I'd like to give this bug a shot!

After a brief skim through some of the source, my plan is to put this check in `Driver::buildInputs` (https://github.com/apple/swift/blob/aee81d272f3147c0a9b610956e72a7c0772b8bcb/lib/Driver/Driver.cpp#L914). Right alongside the check that two swift sources don't have the same filename and the check that source files exist. If this is the wrong place to do it or if I should have emailed swift-dev before claiming this bug or something, please let me know!

[belkadan]

I think that's a reasonable place to put the check. It is a little funny that we have to hardcode "main.swift" in another place; maybe that should be moved up to Strings.h.

[belkadan]

Ah, wait, hang on. There's also the NSApplicationMain and UIApplicationMain attributes, which can generate main functions from files not named "main.swift". We don't find those until after we've type-checked all the files.

[WFT]

Oh, I didn't think about NSApplicationMain / UIApplicationMain. Thanks for the reminder! It's too bad — my solution worked well in cases without the artificial main attributes.

So given that we have to wait until at least type-checking, it seems to me that we have to put this in the frontend. As I understand it, the driver has no knowledge of anything that has happened during type-checking. On the other hand, the frontend doesn't know that we're in -emit-executable mode — only that it's supposed to be emitting an object file. So, unless there's something that I'm missing (totally possible!) it seems like the only way to resolve this bug is by adding a frontend flag (either something like -warn/error-about-missing-entry-point or something like -emitting-for-executable). That seems pretty heavy handed for such a minor improvement, but I don't know what the philosophy is on adding frontend flags (given that they won't be seen by the average user).

I'd love to hear what you think @belkadan! Should I go ahead and add some frontend flag for this? Or should I keep looking for some step in the compiler that both knows about -emit-executable and attribute type-checking? Or should I drop this bug because it's too small to warrant a frontend flag?