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!

[AttilaTheFun]

@tshortli Following up here, are there better ways to accomplish this? Alternately, could we add a way to suppress this warning?

[tshortli]

This PR that @allevato is working on may be of interest: #78463.

In the meantime, if your existing system is working well I'm not sure I understand what the problem is. Why is it important that there not be a warning? I'm finding it hard to justify either course of action (removing the warning entirely or adding a flag to suppress the warning) since this output was not designed to be used in the purpose you are using it for.

[AttilaTheFun]

@tshortli The warnings just produce a lot of noise which developers dislike and also make it more difficult to catch real issues.

We have over 10,000 static libraries in our codebase with 2,000+ and growing in Swift. All of the swift modules emit this warning. If the warning is of no concern to us and we have no plans to address it, it would be nice to be able to suppress it somehow.

Also we intend to use the new feature introduced in Swift 6.1 that allows us to enable / disable Werror for groups of warnings and I'm not sure if this one is compatible.

Re: @allevato 's PR, does the AST dump include fully-qualified type information? I initially tried using SwiftSyntax to parse the AST but it's often missing the information necessary to determine what modules types came from, as this is determined through inference by the type checker.

[allevato]

Re: @allevato 's PR, does the AST dump include fully-qualified type information? I initially tried using SwiftSyntax to parse the AST but it's often missing the information necessary to determine what modules types came from, as this is determined through inference by the type checker.

My current plan (what the PR does right now) is for the JSON AST to represent types via their mangled strings, because it's both extremely compact (important for the JSON AST dump because real code being analyzed will produce very large outputs) and completely specifies everything about the type (it's fully qualified as well as retaining any modifiers, generic arguments, and so forth). Clients could then demangle that string to extract whatever information they need out of it (either by using the swift-demangle tool or linking to libDemangling directly from the compiler sources).

(Personally, I would push back on any attempt to write the types differently than that in the JSON AST, because other representations would be strictly worse than the mangling on one or more metrics. Printing the types as source-like would still require clients to parse them and would be less accurate than walking the demangling, expanding the type structure directly into the JSON would bloat it significantly, and so forth.)

FWIW, I agree with @tshortli that this warning is providing important information. We had considered doing similar kinds of analysis of .swiftinterface files a while back and decided against it because we weren't sure the outputs could be trusted for non-resilient modules and we didn't want to tie ourselves to more unsupported approaches than we needed to, lest they break in the future.