Swiftc cannot find files when passing relative paths going up directory levels

I'm very new to Swift, so pardon my ignorance, but I'm trying to build Swift examples that will run on Windows, Linux, and Mac. And noticed a problem only on Windows. If you pass a source file going up a directory, swiftc says it can't find the file. For example, "swiftc ..\somefile.swift". Any idea how to fix this? This works on Mac and Linux just fine. Going down relative directories works fine. For example, "swiftc .\blah\blah\somefile.swift". I installed swift-5.7.3-RELEASE-windows10.exe.

Please try with the latest snapshots off of main, this sounds like a bug in swift-tools-support-core which impacts the swift-driver.

I finally got around to testing the snapshots. I tried using a development branch dated 2023-2-27 and 2023-4-1 and they also did not work.

Interesting. Do you have a simple test case that you can share for this? swift-llbuild/Package.swift at main ยท apple/swift-llbuild (github.com) is one example of this that I was running some time ago.

I built a simple example, with a bat script that works and one that fails, and a bash script that works on linux that you can see matches the one that fails on Windows. But how do I get it to you? It's a zip file with *.swift, *.bat, and *.sh files. This blog only allows me to upload images.

The bash script isn't particularly helpful; the batch file seems odd. Could you reproduce it with CMake perhaps? The best way to share it may be through GitHub then.

The bat and bash scripts just run the swiftc command, where you can see "../" works in bash on Linux but not bat on Windows. I created the following GitHub repo:GitHub - soraoka/swifttest: Shows an example of .. works on linux but not windows

Batch scripts can be run by anyone regardless what IDE they might be using. So, the example I provided doesn't require CMake to be installed on Windows. I also provided a bash script. So, anyone can run the example on Windows, Linux, or Mac with no dependent application, libraries, or software. The only software it requires is the swiftc compiler (and the OS).

Path resolution for Swift is broken on Windows ever since the port exists, and it finally "broadens to the compiler" when Swift 5.7 makes Swift Driver the only option.

I've tried to solve the problem dating back to 2021, but unfortunately @compnerd insisted that he cannot reproduce the issue and regarded it as "corner case for a corner case":sweat_smile: Sorry to Windows users, you could have not met this issue if someone can assure him at that time.

That's unfortunate. I sent him an sample code that reproduces the problem very plain and simple. Oh well, I guess I'll live with the bug.

I don't know what to say here ... there aren't exactly clear instructions on how to reproduce the issue. However, I think that what you expect is this?

>git clone https://github.com/soraoka/swifttest
Cloning into 'swifttest'...
remote: Enumerating objects: 33, done.
remote: Counting objects: 100% (33/33), done.
remote: Compressing objects: 100% (28/28), done.
remote: Total 33 (delta 3), reused 33 (delta 3), pack-reused 0Receiving objects:  57% (19/33), 8.84 MiB | 17.66 MiB/s
Receiving objects: 100% (33/33), 10.21 MiB | 18.09 MiB/s, done.
Resolving deltas: 100% (3/3), done.
>cd swifttest\samples\TestInterfaces
>.\runExample_doesnotwork.bat
Please ensure the libraries are in your path
For example "set PATH=..\..\lib\;%PATH%"
> path ..\..\lib;%Path%
>.\runExample_doesnotwork.bat
   Creating library .\bin\TestInterfaces.lib and object .\bin\TestInterfaces.exp
Running example
LoadLibraryW failure: 126
TestInterfaces/Loader.swift:33: Fatal error: Could not open 'DllMain.dll' ..
Current stack trace:
0    (null)                             0x00007ffe9d8a1c10 swift_stdlib_reportFatalErrorInFile + 132
"Error executing TestInterfaces.exe"

I'm running a pretty recent snapshot on main and it seems to work as intended?

Hey Saleem,
The latest development branch worked!!! I got the same results you did. I tested it on our production system and it worked great. Thank you for fixing this issue. Now all my scripts for Mac, Linux, and Windows look the same.
--Tom