Is this a `swiftc` bug? "error: module name "foo" is not a valid identifier"

Using Swift
, ,
1

I already filed a radar (rdar://FB9726200, OpenRadar) for this thinking it was an Xcode issue, but now I'm wondering it it's an issue in swiftc.

Merely adding a file to one of my targets it makes it fail to build with:

error: module name "ca.momchilov.Demo-Privileged-Helper-App.helper" is not a valid identifier
Command CompileSwiftSources failed with a nonzero exit code

Unchecking the target membership box for that file makes the project build fine again (even though the product module name hasn't changed at all in doing that).

This issue is in a small dummy project, which I'd be glad to share (what would be the best way? IDK if it's a good idea to post random Google Drive download links on a forum like this). I don't know which specific reproduction steps cause the issue, though.

Is this something I should file on bugs.swift.org?

2

Is it the first Swift file in that target? And does that target have a custom MODULE_NAME build setting? That could explain how you got into this scenario.

1 Like
3

Hey Jordan,

I already have a Swift file in target (main.swift). I created it from the Xcode "command line tool" template, choosing Swift as the default language.

I have manually set my PRODUCT_BUNDLE_IDENTIFIER, PRODUCT_MODULE_NAME, and PRODUCT_NAME:

PRODUCT_BUNDLE_IDENTIFIER = "ca.momchilov.Demo-Privileged-Helper-App.helper";
PRODUCT_MODULE_NAME = "ca.momchilov.Demo-Privileged-Helper-App.helper";
PRODUCT_NAME = "ca.momchilov.Demo-Privileged-Helper-App.helper";

(As far as I understand it, all three have to be the same for a privileged helper tool.)

Though this doesn't seem to be an issue unless I add any further Swift files to the target.

Idk how safe it is to be running random Xcode projects from some random guy on the internet, but I've uploaded my source to GitLab so people can take a look. (I don't have any pre/post build scripts or anything like that)

4

Ahh, yeah, PRODUCT_MODULE_NAME does have to be a valid identifier. It’s weird that it’s being ignored for main.swift though. There’s a feature for single-file modules that infers the module name from the file name (sans .swift) unless it’s an invalid identifier, but that shouldn’t kick in if you explicitly provide one.

5

What makes my identifier invalid? I thought it was the dashes, but it appears not:

error: module name "ca.momchilov.DemoPrivilegedHelperApp.helper" is not a valid identifier
Command CompileSwiftSources failed with a nonzero exit code

edit: ohhhhh it has to be a valid Swift identifier?

6

Yes, module names have to be a valid Swift identifier to allow disambiguating symbols by module.

7

What do you guys think about improving the diagnostic to be more specific about what exactly makes the identifier invalid?

https://github.com/apple/swift-driver/pull/893/files#diff-22af3f561add4c394658e9249278ca06e8fd743f2139342e22217c0be0fc6210R25-R69

8

I changed by module name to just DemoPrivilegedHelperhelper, and got:

<unknown>:0: error: cannot load module 'main' as 'DemoPrivilegedHelperhelper'

I nuked derived data (a well-ingrained habit.), and now it builds fine! :white_check_mark:

I think this diagnostic should also be improved. Nothing about it suggests that the module cache is the issue, and that it should be cleared.

For that matter, couldn't we just directly clear the module cache in this case?

9

I think the Swift driver behaviour is correct here: https://github.com/apple/swift-driver/blob/f9821a1b19fde0e319ff9b69049dd9aea6fa4174/Sources/SwiftDriver/Driver/Driver.swift#L2106-L2107

The issue resides in Xcode. When there's more than the main.swift file in the target, the swiftc invocation contains:

-module-name DemoPrivilegedHelperhelper

But when I remove the second file, it uses:

-module-name main
10

Hrm, sounds like Xcode is manually doing the same thing the compiler is doing, but it shouldn’t do that when the module name is customized. Worth filing a Feedback!

Changing the diagnostic seems like a good idea; it clearly wasn’t clear enough.

I’m not sure why the module cache mattered in this case. I guess that could be a separate Feedback. (I’m not convinced it’s something you could see with just the compiler or SwiftPM.)

1 Like