Support for suppressing warnings in specific packages

[watt]

There's a strategy discussed on the bazelbuild community slack for suppressing warnings in external dependencies that works like this:

Add these lines to .bazelrc to disable warnings both remote and local

build --features=suppress_warnings
build --features=swift.suppress_warnings

then add these lines to REPO.bazel to re-enable warnings for in-repo files

repo(
    features = [
        "-suppress_warnings",
        "-swift.suppress_warnings",
    ],
)

This works, but is an all-or-nothing approach.

One can also disable warnings on a specific repo by using a patch, but this is cumbersome to create. It would be nice to be able to suppress warnings at a package level more conveniently, perhaps using configure_package.

[cgrindel]

I have not looked into this much. If you have an idea for implementation, I would be glad to review it.

[jschear]

I'd like to contribute here. I believe all we need to do in the BUILD file generation side is add swift.suppress_warnings to swift_library's features attribute. The more involved part is deciding what the API should look like:

• We could add a suppress_warnings boolean attribute to the from_package tag class, which would turn this feature on or off for all packages.
• We could add a suppress_warnings boolean attribute to the configure_package tag class, which would turn this feature on or off for a specific package.
• We could add a swift_features string list attribute (to either the from_package or configure_package tag classes), to configure features globally or per-package.
• We could add an additional_swift_copts string list attribute (to either the from_package or configure_package tag classes) to allow for more generic configuration of swift_copts globally or per-package.

Do you have a preference @cgrindel? I'm leaning towards adding swift_features both globally and per-package -- adding a flag just for suppress_warnings feels like it could lead to an unnecessarily complicated API if more features are ever requested, and additional_swift_copts feels a bit low-level when the concept of features already exists.

[brentleyjones]

We could add a swift_features string list attribute

I really like this one.

We could add an additional_swift_copts string list attribute

This one is interesting. I could see this being really powerful, e.g. enabling optimization / WMO for all or certain deps.

to either the from_package or configure_package tag classes

Probably both?

[cgrindel]

I'm leaning towards adding swift_features both globally and per-package -- adding a flag just for suppress_warnings feels like it could lead to an unnecessarily complicated API if more features are ever requested, and additional_swift_copts feels a bit low-level when the concept of features already exists.

I agree. Thanks for taking up the mantle.

[jschear]

Great, I'll get to work on adding swift_features to from_package (for global configuration) and configure_package (for per-package configuration).

I also just realized https://github.com/bazelbuild/rules_swift/blob/master/doc/rules.md#swift_package_configuration exists, does anyone know if that can be used to configure packages outside the root module?