Remove outdated warning about swift interfaces without library evolution

[AttilaTheFun]

This warning was introduced over five years ago in this PR by @jrose-apple
#24420

It sounds like the deficiencies in the 4.X language mode were resolved in the 5.X mode, and we're on 6.X now.

Warn when emitting an interface using -swift-version 4 or -swift-version 4.2: If the Swift project ever drops Swift 4 mode or Swift 4.2 mode, that would break modules using those modes in their interface, so put an unsilenceable warning in for using those modes to nudge interface emitters to Swift 5.

Also warn when emitting without -enable-library-evolution. Module interfaces don't yet carry enough information to correctly describe the binary interface of a module compiled without -enable-library-evolution, but we don't want to make this an error because that would make it harder to work towards getting it in the future.

rdar://problem/47792595

Without being able to access the radar, I'm not sure if there are any outstanding issues, but we're using Swift interfaces in Swift 6 without library evolution enabled and it seems to work fine (though it does print this warning).

Out app has hundreds of Swift modules, and enabling library or module evolution for the entire dependency graph is probably inappropriate. However, we are using the .swiftinterface files for our dependency injection system, and it would be great to remove this warning if it's no longer relevant.

[tshortli]

I'd prefer that we not remove this diagnostic, it is very much still relevant for the same reasons it was first introduced. This aspect of textual interfaces is still true:

Module interfaces don't yet carry enough information to correctly describe the binary interface of a module compiled without -enable-library-evolution

Being a module description for compilation is the primary purpose of textual interfaces, and there has not been any work done to make them suitable for use during compilation of dependents without library evolution enabled.

If we were to remove this warning, we would potentially to add an error on the consuming side to make sure it's clear that it's not supported.

However, we are using the .swiftinterface files for our dependency injection system, and it would be great to remove this warning if it's no longer relevant.

Can you elaborate on what it means to use .swiftinterface files for dependency injection? There are other ways to output a textual description of a module that may be a better input for your system.

[AttilaTheFun]

@tshortli Thanks for your response!

Can you elaborate on what it means to use .swiftinterface files for dependency injection? There are other ways to output a textual description of a module that may be a better input for your system.

I'm open to alternatives if there are better options.

In our DI system, we're currently parsing the .swiftinterface files in order to find conformances to protocols defined in our core library and parse the parameters from memberwise initializers.

For example, we have a Provider protocol which can be used to provide dependencies:

public protocol Provider<Interface> {
    associatedtype Interface
    func provide() -> Interface
}

This can be implemented by an object which depends on some set of other types via its initializer:

public final class FooServiceProvider: Provider {
    private let barService: BarService
    public init(barService: BarService) {
        self.barService = barService
    }
    public func provide() -> FooService {
        return FooServiceImpl(barService: self.barService)
    }
}

Here FooServiceProvider provides an instance of the FooService and it requires an instance of the BarService which will be fulfilled by another provider.

We're using .swiftinterface files instead of parsing the source files, because they include the fully qualified types and all macros have been expanded and compiled.

We need the fully qualified types because if multiple modules define a type of the same name, we need to disambiguate that. Also this allows us to provide and consume Objective-C dependencies like UIKit.UIViewController.

This system has been working very well and we'd like to retain these capabilities, but I'm not sure what other options there are to obtain this information.

Thanks!