Warnings-as-errors exceptions

They aren’t used for compiling against other modules when resiliency is enabled?

I believe if there's a swiftmodule present (the file, the serialized AST) the compiler will use it, assuming it'd be redundant to start over from the swiftinterface, but it's been a long time since I worked on this!

It still works the way @jrose describes. Binary modules are generally preferred when present and compatible with the compiler because it's more straightforward and efficient to do so. Also, for some dependents in some build configurations the binary module is the only representation of the module that carries enough information to build the dependent (e.g. @testable import).

I agree that warnings that would be emitted when building a module from its .swiftinterface should not be surfaced to clients and that it should not be possible to turn them into errors, either. The right time to observe and address these diagnostics is when the module is built from source. Once the build of a dependent has started, the module interface is an immutable artifact that the client cannot alter so any diagnostics that are specific to building the module from its interface are mainly just going to be a nuisance.

4 Likes

This addition is absolutely fantastic. It can't land soon enough.

For years, we struggled with deprecation warnings and having to deal with -warnings-as-errors. We ultimately had to disable the option and open the gate for so many regression issues being introduced - a pain.

Thank you for pushing through the status quo and adding such a missed compiler feature.

2 Likes

I was wondering when I can use this great option.

I hope to ship the initial support with the 6.1 release.

5 Likes