The Windows compiler & @main

Development Windows
1

I've a command-line app which compiles and runs on macOS and Ubuntu but fails to compile on Windows 10 with the most recent production compiler. It starts:

//
//  Created by Gavin Eadie on 11/11/22.
//

import PropLib

@main
public struct PropApp {

    public static func main() {
    :  :  :

.. and the compiler complains:

.. swift:10:1: error: 'main' attribute cannot be used in a module
                                      that contains top-level code
   @main

.. swift:1:1: note: top-level code defined in this source file
   //

Not only is the @main attribute rejected but the "top-level code" it doesn't't like is the first line - the comment //. I don't travel in the Windows world, so there are many things I don't know, but it seems that correct Swift ought to be correct across platforms.

I'm not asking for help to fix this, that's easy. I'm wondering how much the compilers' behavior varies between platforms, and seeking advice on how to appropriately report differences. I can bring them to this forum (like I am now), I could make them issues in the repo .. but it's not right to do nothing.

2

The compiler is not rejecting //; the diagnostic just always points to the first line of the file, and it's misleading because it has nothing to do with any top-level code in that file. This is a build configuration issue just as with:

2 Likes
3

This behaviour is uniform across the platforms AFAIK. In fact, incidentally, there is a different thread about this already, which @xwu already shared.

4

sorry to bump the old thread, but as of 5.9.1, the behavior is not uniform across all platforms, only Windows seems to be affected by this. i noticed the issue today while fixing some CI bitrot in the swift-png library.

1 Like
5

We have this problem on Windows 10 systems only and not on Windows 11, but of course this might be some kind of coincidence. See my comment in the announcement of Swift Swift 5.9.1 for Linux and Windows.

Unfortunately we could not yet reduce our project to the point where this problem persists and we could share the code. But with your open source library, there is a change that other people can examine this.

Following the Windows 10 vs. 11 idea (which of course might be the wrong path, there were some scepticism in the other topic), which OS version are you using? I can test on both versions, which is the exact package (swift-png? which version or branch?) and the command (just compilation or testing) that fails?

6

the CI runs on Windows Server 2022, which according to wikipedia, is a Windows 10 system.

this is the GitHub commit

CI action:

                    swift --version
                    swift build

                    swift --version
                    swift run -c debug PNGTests
                    swift run -c release PNGIntegrationTests
                    swift run -c release PNGCompressionTests
7

I just took the current head (09790c1c642ff71ed751dcdda965b5621079292a) of swift-png, and compilation (swift build). was successful on Windows 11, but had the mentioned error ('main' attribute cannot be used in a module that contains top-level code) on Windows 10. This was the same with Swift 5.9(.0) and Swift 5.9.1.

On both systems: Visual Studio 2022 17.7.5, MSVC v143, Windows 10 SDK 10.0.19041.0. (Note that in the other topic I also tried other Windows SDK versions for my own project, that did not change anything in this regard.)

It only tested it on one Windows 10 system and on one Windows 11 system, and so it should probably be confirmed by others.

2 Likes
8

thanks for taking the time to confirm the issue, i am glad i am not going crazy.

Windows 2022 is currently the most recent Windows image that GitHub Actions supports, so it is not possible for swift-png (or any other public project) to upgrade to a Windows 11 runner on GitHub Actions.

the effective consequence of this is that swift-png does not have CI coverage for Windows, and therefore cannot be said to support Windows any longer.

2 Likes
9

Just a note in case it's useful for somebody else. Workaround is swift build -Xswiftc -parse-as-library or

swiftSettings: [
.unsafeFlags(["-parse-as-library"], .when(platforms: [.windows])),
]

added to the target in Package.swift.

1 Like