Build settings for warning treating rules (SE-0443, draft)

[DmT021]

This change adds warning control settings. The flags for Swift targets are described by SE-0443, for Clang targets - here.

Common API for all three languages (Swift, C, and C++)

/// The level at which a compiler warning should be treated.
public enum WarningTreatLevel: String {
    /// Treat as a warning.
    ///
    /// Warnings will be displayed during compilation but will not cause the build to fail.
    case warning

    /// Treat as an error.
    ///
    /// Warnings will be elevated to errors, causing the build to fail if any such warnings occur.
    case error
}

public static func treatAllWarnings(
    as level: WarningTreatLevel,
    _ condition: BuildSettingCondition? = nil
) -> SwiftSetting // or CSetting or CXXSetting

public static func treatWarning(
    name: String,
    as level: WarningTreatLevel,
    _ condition: BuildSettingCondition? = nil
) -> SwiftSetting // or CSetting or CXXSetting

Warning control methods for C and C++ only

public static func enableWarning(
    name: String,
    _ condition: BuildSettingCondition? = nil
) -> CSetting // or CXXSetting

public static func disableWarning(
    name: String,
    _ condition: BuildSettingCondition? = nil
) -> CSetting // or CXXSetting

Settings and their corresponding compiler flags

Method	Swift	C/C++
treatAllWarnings(as: .error)	-warnings-as-errors	-Werror
treatAllWarnings(as: .warning)	-no-warnings-as-errors	-Wno-error
treatWarning(name: "XXXX", as: .error)	-Werror XXXX	-Werror=XXXX
treatWarning(name: "XXXX", as: .warning)	-Wwarning XXXX	-Wno-error=XXXX
enableWarning(name: "XXXX")	N/A	-WXXXX
disableWarning(name: "XXXX")	N/A	-Wno-XXXX

Notes

• The order of settings is preserved when passing the flags to the compilers.
• Warning control settings have no effect when a target being built is remote. SwiftPM will strip all of the warning control flags and substitute them with an option for suppressing warnings (-w for Clang and -suppress-warnings for Swift).

[DougGregor]

@swift-ci test

[DougGregor]

Aside from the two places where we can go quadratic in the number of command-line arguments, this is looking good to me. But I'm not super familiar with the SwiftPM code base.

[DougGregor]

This loop could be a filter, which would make it linear-time rather than quadratic.

[DougGregor]

Also technically quadratic. Even though it's a little ugly, I think I'd still rather do it with a filter

var removeNextArg = false
args = args.filter { arg in
  if removeNextArg {
    removeNextArg = true
    return false
  }
  switch arg {
  case "-warnings-as-errors", "-no-warnings-as-errors":
    return false
  case "-Wwarning", "-Werror":
    removeNextArg = true
    return false
  default:
    return true
  }
}

[DmT021]

Yes, the quadratic complexity is an oversight on my part. Good thing you noticed.
TBH, using an external state in a filter makes me a bit uneasy. The documentation for filter doesn't guarantee that the predicate will be invoked in any particular order, so I'd try to avoid it.
I don't insist though. If you think a filter here is fine, I don't mind. But what do you think about something more "manual", e.g:

var readIndex = args.startIndex
var writeIndex = args.startIndex
let endIndex = args.endIndex
while readIndex < endIndex {
    let arg = args[readIndex]
    switch arg {
    case "-warnings-as-errors", "-no-warnings-as-errors":
        break
    case "-Wwarning", "-Werror":
        readIndex += 1  // -Wwarning and -Werror have an argument
        if readIndex >= endIndex {
            throw InternalError("Unexpected '\(arg)' at the end of args")
        }
    default:
        if readIndex != writeIndex {
            args[writeIndex] = args[readIndex]
        }
        writeIndex += 1
    }
    readIndex += 1
}
if writeIndex < endIndex {
    args.removeSubrange(writeIndex..<endIndex)
}

[dschaefer2]

A couple of general questions. Placing these flags in the package manifest, means all consumers of this package will build with the same settings. I was just wondering if it's a concern that consumers may want to set them differently. For example, if they are specifying additional warning setting flags on the swift build command lines, which ones take precedence.

Also, as we're working on adopting Swift Build to replace our native build system, we would need to make sure this is handled there as well.

[dschaefer2]

Mind you the pitch and evolution proposal predates my participation so maybe this has already been addressed. I'll need to catch up.

[DmT021]

I was just wondering if it's a concern that consumers may want to set them differently. For example, if they are specifying additional warning setting flags on the swift build command lines, which ones take precedence.

That's a good question. AFAIK, the additional flags (-Xcc, -Xcxx, -Xswiftc) are placed after the internally generated flags, but I didn't really check that. I'll dive into it later. If it's not the case, I think we should make it so. However, I need a confirmation from the maintainers that that's really the desired behavior.
If that's the guaranteed order of flags, then users will be able to either override or extend the warning treating rules. The rules are evaluated left to right in the compilers. So appending -[no-]warning-as-errors overrides everything that is earlier in the command line.

Also, as we're working on adopting Swift Build to replace our native build system, we would need to make sure this is handled there as well.

I've raised a discussion about that, but it seems like the Swift Build maintainers prefer a simpler approach to these flags. swiftlang/swift-build#248

Mind you the pitch and evolution proposal predates my participation so maybe this has already been addressed. I'll need to catch up.

The original proposal (SE-0443) doesn't address this API, but we're working on fixing that. We will probably write a new pitch.

[DmT021]

@swift-ci Please test

[dschaefer2]

@swift-ci please test windows

[DmT021]

For example, if they are specifying additional warning setting flags on the swift build command lines, which ones take precedence.

Following up on this question. The additional arguments the used provided are placed after the ones SwiftPM generates.
The code responsible for this behavior has comments about that, which leads me to believe it was intentional.
For C/C++
For Swift

So if we consider the following Package.swift:

let package = Package(
    name: "MyExecutable",
    platforms: [
        .macOS(.v13),
    ],
    targets: [
        .target(
            name: "cfoo",
            cSettings: [
                .enableWarning(name: "all"),
                .disableWarning(name: "unused-parameter"),
                .treatAllWarnings(as: .error),
                .treatWarning(name: "unused-variable", as: .warning),
            ]
        ),
        .target(
            name: "cxxfoo",
            cxxSettings: [
                .enableWarning(name: "all"),
                .disableWarning(name: "unused-parameter"),
                .treatAllWarnings(as: .error),
                .treatWarning(name: "unused-variable", as: .warning),
            ]
        ),
        .executableTarget(
            name: "swiftfoo",
            swiftSettings: [
                .treatAllWarnings(as: .error),
                .treatWarning(name: "DeprecatedDeclaration", as: .warning),
            ]
        ),
    ]
)

And build it with additional arguments like this:

swift-build --very-verbose -Xcc -Wno-error -Xswiftc -no-warnings-as-errors

We will get the following invocations of the compilers:

For cfoo:
clang ... -Wall -Wno-unused-parameter -Werror -Wno-error=unused-variable ... -Wno-error ...
For cxxfoo:
clang ... -Wall -Wno-unused-parameter -Werror -Wno-error=unused-variable ... -Wno-error ...
For swiftfoo:
swiftc ... -warnings-as-errors -Wwarning DeprecatedDeclaration ... -no-warnings-as-errors -Xcc -Wno-error ...

Given that these flags are evaluated left-to-right it gives the user some control here at the build stage.
However, it doesn't compose well with -suppress-warnings, as it's mutually exclusive with the other flags:

swift-build --very-verbose -Xswiftc -suppress-warnings

swiftc ... -warnings-as-errors -Wwarning DeprecatedDeclaration ... -suppress-warnings ...

error: conflicting options '-warnings-as-errors' and '-suppress-warnings'
error: conflicting options '-Wwarning' and '-suppress-warnings'