fix: Attempt to work around PackagePlugin.Path deprecation

[paulgessinger]

Currently, the build of this package (and dependees) produces a number of warnings like:

warning: 'appending' is deprecated: Use `URL` type instead of `Path`.
 51 | 
 52 |         // Setup folder
 53 |         let genFolder = context.pluginWorkDirectory.appending(["ProtocolGen"])
    |                                                     `- warning: 'appending' is deprecated: Use `URL` type instead of `Path`.
 54 |         try FileManager.default.createDirectory(
 55 |             atPath: genFolder.string, withIntermediateDirectories: true

This (to my understanding) is because the type PackagePlugin.Path is deprecated in favor of Foundation.URL, but the replacements accessor properties are not universally implemented until (I think) version 6.1.

In this PR, I'm attempting to remove these warnings. In Plugin.swift this is relatively straightforward, but in SwiftPackageTarget.swift it's a bit tricky:

The procotol SourceModuleTarget does not currently include the needed var directoryURL: URL, even though both (and I think those are the only two types that conform to this protocol) ClangSourceModuleTarget and SwiftSourceModuleTarget have this property. I'm adding here a workaround that tries to downcast the incoming SourceModuleTarget to either of these types, and then packages it in a temporary helper protocol CompatSourceModuleTarget that exposes the directoryURL property.

I'm not sure if this is the best way to this, but I thought I'd open a PR to discuss it. I can't run the tests included in the repo (even on main they fail for me), so I don't know if the changes are fully correct, aside from compiling without warnings.

Let me know what you think!

[soumyamahunt]

Wouldn't this change the path for generated source files?

[paulgessinger]

Overlooked this, yes. I'll change it

[soumyamahunt]

Why not use an extension to define this property for older versions instead? Won't that be much simpler than current implementation?

[paulgessinger]

You mean an extension that adds it to SourceModuleTarget and then does the downcast to call into the underlying property? Otherwise, I'm not sure I'm following what you're suggesting.

[soumyamahunt]

I was thinking an implementation of directoryURL that is used for older swift versions. This could live as an extension while restricted with compiler directive.

This would avoid breaking change for older versions.

[paulgessinger]

Hm, but wouldn't I need this in the protocol that's being used internally? The underlying types expose directoryURL already in Swift 6, but I don't know how I could access the implementation without downcasting.

[soumyamahunt]

@paulgessinger I was thinking extension with compiler directive like this:

#if swift(<6.1)
extension SourceModuleTarget {
    var directoryURL: URL {
        // create directory url for older versions
    }
}
#endif

This way newer properties can be used providing backwards compatibility.

[paulgessinger]

But that would still require downcasting inside the implementation, since I can't convert the Path type to URL without triggering the deprecation warning, wouldn't it?

[soumyamahunt]

since I can't convert the Path type to URL without triggering the deprecation warning

The warning will only be generated for Swift 6 version if I am not wrong. For other versions I don't think warning will be generated. For me that is an acceptable solution than dropping compatibility for Swift 6 and below.

[paulgessinger]

Right. This PR is an attempt to avoid the warning in Swift 6

[soumyamahunt]

@paulgessinger may be you can do something like this that handles warning with Swift 6 version as well:

#if swift(<6.1)
extension SourceModuleTarget {
    var directoryURL: URL {
        #if swift(<6)
        // create directory url for older versions convert the Path type to URL
        #else
        // create directory url with down-casting
        #endif
    }
}
#endif

[soumyamahunt]

Wouldn't this change break compatibility with older Swift version?

[paulgessinger]

Yes I think so. That would be a tradeoff. Maybe it's possible to partition the implementation into different functions that are called based on the Swift version to avoid the deprecated behavior only in Swift 6.