[Diagnostics] Add fix-it to @main struct without main static function.

[CrazyFanFan]

Resolves #58518

It will create four different fix-its:

    static func main() {
        <#code#>
    }
 
    static func main() throws {
        <#code#>
    }
 
    static func main() async {
        <#code#>
    }
 
    static func main() async throws {
        <#code#>
    }

[AnthonyLatsis]

Nice!

Please add a test case with a nested @main struct to make sure we got the indents right.

[CrazyFanFan]

@AnthonyLatsis Thanks for the review! All issues have been addressed based on your feedback.

[AnthonyLatsis]

One more round. Are you using clang-format?

[CrazyFanFan]

One more round. Are you using clang-format?

@AnthonyLatsis Yes, I ran clang-format before submitting:

git-clang-format HEAD~2
git add .
git commit --amend --no-edit

All other review feedback has been addressed as well.

[ahoppen]

Very nice. Looking forward to using this 🤩

[ahoppen]

Nitpick: Should we add two newlines here to separate the generated main function from the remaining body using a newline?

[AnthonyLatsis]

I don’t have a clear preference. Ideally (not in this PR!), I imagine a formatCodeForInsertion function that parses a given string into a SwiftSyntax tree and formats it using SwiftBasicFormat (indentation, separation) for insertion at a given location.

[ahoppen]

The way that Fix-Its and refactorings are designed to work is that the editor applies its own indentation after applying the Fix-It refactoring because it can really know about the user’s preferences (the compiler can only guess based on existing lines). But whether to add a newline is currently an opinionated decision by the compiler.

[CrazyFanFan]

Thank you for the discussion.

I've looked at other fix-it instances in TypeCheckProtocol.cpp and TypeCheckDistributed.cpp, and found that they only add a single \n at the end of inserted code, without additional blank lines.

Considering this, and editors applying indentation based on user preferences, I'm inclined to stay consistent with existing practices and not insert extra blank lines.

Of course, if you have any other thoughts, I'm open to further discussion.

[ahoppen]

Thanks for finding those examples. In that case let’s stick with the existing practice of only adding one newline. 👍🏽

[AnthonyLatsis]

@swift-ci please smoke test Linux

[AnthonyLatsis]

01:57:17  Failed Tests (6):
01:57:17    Swift(linux-x86_64) :: attr/ApplicationMain/attr_main_arguments.swift
01:57:17    Swift(linux-x86_64) :: attr/ApplicationMain/attr_main_dynamicCallable.swift
01:57:17    Swift(linux-x86_64) :: attr/ApplicationMain/attr_main_dynamicMemberLookup.swift
01:57:17    Swift(linux-x86_64) :: attr/ApplicationMain/attr_main_extension_nofunc.swift
01:57:17    Swift(linux-x86_64) :: attr/ApplicationMain/attr_main_return.swift
01:57:17    Swift(linux-x86_64) :: attr/ApplicationMain/attr_main_struct_from_two_protocols_one_missing.swift

Let me know if you need help running the tests locally.

[CrazyFanFan]

01:57:17  Failed Tests (6):
01:57:17    Swift(linux-x86_64) :: attr/ApplicationMain/attr_main_arguments.swift
01:57:17    Swift(linux-x86_64) :: attr/ApplicationMain/attr_main_dynamicCallable.swift
01:57:17    Swift(linux-x86_64) :: attr/ApplicationMain/attr_main_dynamicMemberLookup.swift
01:57:17    Swift(linux-x86_64) :: attr/ApplicationMain/attr_main_extension_nofunc.swift
01:57:17    Swift(linux-x86_64) :: attr/ApplicationMain/attr_main_return.swift
01:57:17    Swift(linux-x86_64) :: attr/ApplicationMain/attr_main_struct_from_two_protocols_one_missing.swift

Let me know if you need help running the tests locally.

@AnthonyLatsis Thank you for the detailed test failure information.​

All issues you mentioned have been fixed. Additionally, all tests in test/attr/ApplicationMain/ have been run in my local before this update, addressing the previously overlooked cases.​

Please let me know if you spot anything else or have further suggestions.​

[AnthonyLatsis]

Thanks! Please tidy up your history before we go for merge.

P.S. You are welcome to add a test for if (hasAsyncSupport) { in a follow-up.

[AnthonyLatsis]

@swift-ci please smoke test Linux

[CrazyFanFan]

@AnthonyLatsis Hi,

Just to confirm: by tidying up history, do you mean amending/combining commits?
I’d like to add the test for if (hasAsyncSupport) but am unsure how to set up an Async-unsupported environment. Any tips?

Thanks!

[AnthonyLatsis]

Just to confirm: by tidying up history, do you mean amending/combining commits?

In this case I mean squashing the "review feedback" commit into the original.

I’d like to add the test for if (hasAsyncSupport) but am unsure how to set up an Async-unsupported environment. Any tips?

Try this (async is supported or can be deployed to platform versions aligned with 5.1 and onward):

// RUN: %target-typecheck-verify-swift -parse-as-library -target %target-swift-5.0-abi-triple

// REQUIRES: OS=macosx && CPU=x86_64

@main struct S {}

[CrazyFanFan]

I've squashed the "review feedback" commit into the original as suggested. I've also added the test for if (hasAsyncSupport). Let me know if anything needs adjusting.

Thanks！

[AnthonyLatsis]

@swift-ci please smoke test macOS

[AnthonyLatsis]

FYI if you build the project without --swift-darwin-supported-archs=arm64 you will also get a x86_64 stdlib and a test-macosx-x86_64 directory that you can use to run these kinds of tests. You don’t need a x86_64 machine in this case.

[AnthonyLatsis]

@swift-ci please smoke test Linux

[AnthonyLatsis]

@swift-ci please smoke test Windows