feat: expand SWIFTFLAGS with full paths

[stevapple]

This will ensure compatibility with both CMD and PowerShell.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.79%. Comparing base (b939b08) to head (c371ddb).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #74   +/-   ##
=======================================
  Coverage   92.79%   92.79%           
=======================================
  Files          34       34           
  Lines        1082     1083    +1     
  Branches      157      157           
=======================================
+ Hits         1004     1005    +1     
  Misses         77       77           
  Partials        1        1           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[soumyamahunt]

@stevapple is it possible to add validation of this feature in CI?

[stevapple]

@stevapple is it possible to add validation of this feature in CI?

I think this environment variable is not quite useful for modern Swift on Windows toolchains, and its only current usage is for LLDB and REPL, which are uncommon for CI/CD.

Since it's already guaranteed by unit testing, I think it's okay...?

[soumyamahunt]

@stevapple is it possible to add validation of this feature in CI?

I think this environment variable is not quite useful for modern Swift on Windows toolchains, and its only current usage is for LLDB and REPL, which are uncommon for CI/CD.

Since it's already guaranteed by unit testing, I think it's okay...?

While LLDB probably would never be used in CI, some may use REPL. Adding a simple hello world in integration test should be fine.

swift -e "print(\"Hello from REPL\")"

[stevapple]

While LLDB probably would never be used in CI, some may use REPL. Adding a simple hello world in integration test should be fine.

swift -e "print(\"Hello from REPL\")"

Well, the interpreter had never worked as expected on Windows. These flags are mostly legacy companions for swiftc on older Swift releases. We should actually set it only for Swift 5.6 and older versions.

[stevapple]

We should actually set it only for Swift 5.6 and older versions.

Doing this (as well as eliminating support file setup mentioned in #72) requires us to pass/parse the installed version in the post-installation process, which would be explored in a later patch.

[soumyamahunt]

We should actually set it only for Swift 5.6 and older versions.

Doing this (as well as eliminating support file setup mentioned in #72) requires us to pass/parse the installed version in the post-installation process, which would be explored in a later patch.

Please add comment here as well, so it's not missed

[soumyamahunt]

@stevapple can you rebase this PR, I am thinking of adding this as part of next release.

[stevapple]

@stevapple can you rebase this PR, I am thinking of adding this as part of next release.

Done.

[soumyamahunt]

@stevapple thanks for the quick response, can you add following data to SETUPSWIFT_CUSTOM_TOOLCHAINS variables in your fork:

{
    "ubuntu2204": "https://github.com/swiftwasm/swift/releases/download/swift-wasm-5.10-SNAPSHOT-2024-03-30-a/swift-wasm-5.10-SNAPSHOT-2024-03-30-a-ubuntu22.04_x86_64.tar.gz",
    "xcode": "https://github.com/swiftwasm/swift/releases/download/swift-wasm-5.10-SNAPSHOT-2024-03-30-a/swift-wasm-5.10-SNAPSHOT-2024-03-30-a-macos_x86_64.pkg",
    "windows10": ""
}

The CI expects this data to test custom toolchain installations, and hence failing since not present.