apple / swift-tools-support-core Goto Github PK

This needs to be converted to a class to do what it's supposed to do, currently this is very thread-unsafe.

RelativePath today does simple syntactic normalization on non-Windows platforms, eliding path components that are empty or consist of just ., and using .. components to remove parent components, etc. On Windows, RelativePath today instead calls PathCanonicalizeW().

But in general it isn't possible to canonicalize relative paths — the canonicalization needs to be applied to a resulting AbsolutePath, so that the place where an absolute and relative path are joined is canonicalized properly.

So we should change the logic to:

• have RelativePath not try to canonicalize relative paths in isolation
• instead have AbsoluePath canonicalize the resulting absolute path once it has been formed from the absolute and relative components

Hello,

I am trying to compile TSCUtility with swift 5.7 and I receive the following error message.

/Users/ec2-user/project_name/.build/checkouts/swift-tools-support-core/Sources/TSCUtility/FSWatch.swift:848:15: error: cannot assign value of type 'Thread' to type 'Thread?'
                self.thread = thread

self.thread is of type Thread? and thread is of type Thread

I don't think this is a change in Swift 5.7 as I tested the behaviour with the following sample code

@main
public struct test {
    var a : Int?

    public init() {
       let b : Int = 1
       self.a = b
       print(a!)
    }

   public static func main() {
      let _ = test();
   }   
}

ec2-user@ip-172-31-67-99 test % swift --version 
swift-driver version: 1.62.3 Apple Swift version 5.7 (swiftlang-5.7.0.123.8 clang-1400.0.29.50)
Target: arm64-apple-macosx12.0

After update to Xcode 14.1 (from 14.0.1) it's unable to build FSEventStream because of type incompatible object assignment

https://github.com/apple/swift-tools-support-core/blob/main/Sources/TSCUtility/FSWatch.swift#L848

It seems that here https://github.com/apple/swift-tools-support-core/blob/main/Sources/TSCUtility/FSWatch.swift#L826 you are creating object using incorrect Thread type. It takes it from Foundation instead of TSCBasic.

I guess instead of creating thread this way Thread { ... } it's needed to create it next way TSCBasic.Thread { ... }

I try to run a tool that uses TSCBasic.Process.checkNonZeroExit(arguments: arguments) in two threads. The called executable is the same but the arguments differ.

The second call errors with error: close error: Unknown error -1.
This comes from try close(fd: stdinPipe[0]) in Process::launch.

Trying to run swift from emacs on windows (niche use case, I know) I was running into an error about swift not being able to find "swift-test.exe". Checking environment variables, I think I've tracked this down to a combination of emacs using unconventional capitalization, and a case sensitivity inside of SPM.

When run from cmd.exe, the environment variable is Path=C:\..., but from emacs it's PATH=C:\...

From

This brings me finally to a question: Is this a swift bug and/or an emacs bug? As far as I understand, while "Path" is the official casing, environment variables are expected to be treated insensitively on windows (which works a bit unfortunately with swift's representation as [String: String])

I can create a PR to fix this, and I may file a bug against emacs as well, but I wanted to check first, since my windows experience is pretty limited.