# Warnings-as-errors exceptions

**URL:** <https://forums.swift.org/t/warnings-as-errors-exceptions/72925>\
**Category:** Discussion\
**Created:** [July 3, 2024, 8:03pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925 "2024-07-03T20:03:02Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![dmt](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmt/32/30830_2.png) [@dmt](https://forums.swift.org/u/dmt)\
**Post date:** [July 3, 2024, 8:03pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/1 "2024-07-03T20:03:02Z")

</div>

**TLDR**  
I'd like to discuss a design for defining exceptions to the `-warnings-as-errors` rule.

**Background**  
There is a lack of flexibility in how the compiler can be configured to deal with warnings. Specifically, when the `-warnings-as-errors` option is enabled, all warnings are treated as errors unless the `-no-warnings-as-errors` option is also applied, which turns off the rule completely.  
Although having `-warnings-as-errors` enabled is a good hygiene practice, it also has some downsides when it comes to compiler and SDK updates.  
The most obvious example is when a function or type is declared deprecated in an update. Additionally, there are the new concurrency diagnostics introduced in versions 5.9, 5.10, and probably 6.0. There are many more examples as well.  
The problem escalates as the codebase grows. In some projects, the people responsible for the code and those responsible for the infrastructure are different groups. When it comes to a compiler update, the infrastructure team can sometimes face an overwhelming amount of work to address all the newly diagnosed warnings at once.

**Proposed solution**  
I propose a new compiler option `-no-warning-as-error`, which allows users to specify exceptions to the `-warnings-as-errors` option.  
Originally, the format of the option was `-no-warning-as-error <diag_id>`, where `<diag_id>` is one of the diagnostic IDs listed in `include/swift/AST/Diagnostics*.def`.  
However, @ArtemC and @Douglas_Gregor rightfully pointed out that the diagnostic IDs aren't stable and will never be stable, as the compiler continuously improves diagnostics and introduces more specific versions for existing messages, necessitating the creation of new diagnostic IDs.  
So instead it was suggested to follow Clang's model of diagnostic groups whose name are stable across the compiler's versions. And then sort all the existing warnings into these groups.  
For example, these two warnings can be grouped into a single group named `ignored_import`:

```swift
WARNING(sema_import_current_module,none,
        "this file is part of module %0; ignoring import", (Identifier))
WARNING(sema_import_current_module_with_file,none,
        "file '%0' is part of module %1; ignoring import",
        (StringRef, Identifier))

```

Both of these warnings can then be exempted from being upgraded to errors by specifying `-no-warning-as-error ignored_import`.

**It's a lot of work**  
It would require grouping hundreds of warnings and errors into appropriate groups and properly naming these groups. This process involves considerable work, verification, and approval, which may be too much to accomplish all at once.  
So I think it'd be more approachable to do this gradually:

1. **Introduce support for group names**

2. **Temporary Support for Diagnostic IDs**

3. **Complete the Grouping**

* * *

The original discussion is in this PR: [[Diagnostics] Add -no-warning-as-error to except a specific warning from being treated as an error by DmT021 · Pull Request #74466 · swiftlang/swift · GitHub](https://github.com/swiftlang/swift/pull/74466)

---

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [July 3, 2024, 8:25pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/2 "2024-07-03T20:25:51Z")

</div>

I'm guilty of grafting this exact feature on top of our builds in Bazel using those very same unstable IDs, adding `-debug-diagnostic-names` to our compilation commands and scraping the output to upgrade matching warnings into errors, because our teams want some form of warning prohibition that excludes deprecations ([implementation](https://github.com/bazelbuild/rules_swift/commit/66a01374d9ddd087e16f7c81515ee31c031fb7af)). compiler devs: please don't break us 🙏

(The other motivation was to let our users opt-in to a stricter simulation of Swift 6 mode on Swift 5.9-10 compilers, by having a single build setting that flipped on all the Swift 6 upcoming features and making any warnings with the ID `error_in_future_swift_version` into errors instead. It's not perfect since there are known issues with a couple of the checks on older compiler versions, but for 90-95% of the cases we've used it on so far, it's good enough.)

All the past discussions on this topic (typically centered around deprecation warnings) have had a lot of strong opinions (including my own!) in various directions and different ways to envision deprecation suppression that didn't involve a broad compiler flag. Those discussions have ended up hamstrung on details so we haven't made any progress, and I think it's a really unfortunate state to be in.

So I've come around to think that we should just do what you're suggesting here. It's a proven technique that works with other compilers, and _at the very least_ if we only added a single `deprecation` group at the start, the feature would be significantly useful.

---

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [July 3, 2024, 8:39pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/3 "2024-07-03T20:39:02Z")

</div>

I suppose an additional footnote to this is the following: I consider the `-warnings-as-errors` flag in its current state to be unusable without the capability to refine what you enforce. To quote a much older post, it's not even recommended for use in all cases:

> [@Treat warnings as errors except deprecations](https://forums.swift.org/t/treat-warnings-as-errors-except-deprecations/14709/4):
>
> `-warnings-as-errors` is fine for development and incoming pull request hygiene, but we don't recommend using it for production builds, since we add new warnings in new releases for deprecations and new safety issues.

But I'd go further than this—there are often warnings that simply _can't_ be removed from code easily. Some of the new concurrency features have produced diagnostics that we can't immediately drop everything to fix when a new compiler version comes out. Sometimes a bug slips through and a released compiler produces false warnings and we have to wait a release for a [fix](https://github.com/swiftlang/swift/pull/74624). Sometimes the alternative to a deprecated API doesn't work _exactly the same way_ and we need some more time to migrate off of it. There's no development vs. production distinction there, in my mind—and if I have extra enforcement on my dev builds, I'd also want it on my prod builds specifically to ensure that nothing sneaks through (maybe I have a large `#if DEBUG ... #else ...` block that wouldn't get checked otherwise).

---

<div class="post-metadata">

**Author:** ![dmt](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmt/32/30830_2.png) [@dmt](https://forums.swift.org/u/dmt)\
**Post date:** [July 17, 2024, 6:41pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/4 "2024-07-17T18:41:03Z")

</div>

I updated [the pull request](https://github.com/swiftlang/swift/pull/74466) to include support for diagnostic groups, flags to control the behavior of warnings, and several use cases. I defined the groups to include the `availability_deprecated` and `error_in_future_swift_version` warnings, just to have some examples.

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [July 23, 2024, 8:27pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/5 "2024-07-23T20:27:58Z")

</div>

> [@dmt](#):
>
> I propose a new compiler option `-no-warning-as-error`, which allows users to specify exceptions to the `-warnings-as-errors` option.  
> [...]  
> So instead it was suggested to follow Clang's model of diagnostic groups whose name are stable across the compiler's versions.

The pull request describes the approach in more detail, following the way Clang did it, and I think it's a good model. To summarize for the thread here, the options are:

- `-warning-as-error <group name>`: escalates warnings in the named group to errors
- `-no-warning-as-error <group name>`: downgrades warnings in the named group from errors to warnings
- `-warnings-as-errors`: continues to escalate all warnings into errors.
- `-no-warnings-as-errors`: cancels out `-warnings-as-errors`, making all warnings that were escalated to errors warnings again.

> [@dmt](#):
>
> **Introduce support for group names**
> 
> - Create two versions of the `WARNING` and `ERROR` macros: one with a group name argument and one without.
> - Address some of the most popular warnings first.
> - Implement support for the `-no-warning-as-error <group_name>` option.

This all makes sense to me. I think I'd like to ensure that we're thinking ahead to all of the information we want to include in each group, so we don't have to come back and revisit every group.

The only bit of information I know of that I'd like each group to be documented with a snippet of Markdown associated with it (could be in a separate file). Then we can pull these together to document the warning groups in some central way; like [Clang's documentation for diagnostic flags](https://clang.llvm.org/docs/DiagnosticsReference.html#introduction) but with an actual human-written description of "this is the kind of warning you'd see" rather than the diagnostic message diagram's Clang did.

> [@dmt](#):
>
> **Temporary Support for Diagnostic IDs**
> 
> - Implement a temporary special syntax for the remaining warnings: `-no-warning-as-error _id:<diag_id>`, which accepts diagnostic IDs as declared in the `Diagnostics*.def` files.

I'd rather us not have this feature in the first place, because we might find it hard to take it back once we've added it. We have time before the `main` compiler gets stabilized for release: perhaps we can get far enough with adding warning groups before then that we don't need this feature.

> [@dmt](#):
>
> **Complete the Grouping**
> 
> - Gradually sort all diagnostic messages into appropriate groups.
> - Discard support for the temporary diagnostic ID syntax introduced in Step 2.
> - Make the group name parameter mandatory in the `WARNING` and `ERROR` macros.

We can probably make this third bullet stronger: once we land the support for warning groups, we can have a static assert on the number of warnings that have no group. If you add a warning without a group, it fails and the comment tells you to go put it in a group. That'll prevent regressions as we work toward driving the number to zero.

Other things we probably want to consider, although they don't have to happen immediately:

- SwiftPM's SwiftSettings should get some settings to correspond to these compiler flags

- We could pass the diagnostic group name into the serialized diagnostics file as a "category" (Clang does this with warning groups)

- Should we design warning suppression at the same time? `-no-warning <group name>` or similar?

---

<div class="post-metadata">

**Author:** ![dmt](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmt/32/30830_2.png) [@dmt](https://forums.swift.org/u/dmt)\
**Post date:** [July 23, 2024, 9:40pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/6 "2024-07-23T21:40:14Z")

</div>

> [@Douglas\_Gregor](#):
>
> I'd rather us not have this feature in the first place, because we might find it hard to take it back once we've added it. We have time before the `main` compiler gets stabilized for release: perhaps we can get far enough with adding warning groups before then that we don't need this feature.

In case we don't provide support for the `_id:` option we should support the most frequent warnings first. And I'd like hear from the community what are those.

> [@Douglas\_Gregor](#):
>
> we can have a static assert on the number of warnings that have no group. If you add a warning without a group, it fails and the comment tells you to go put it in a group

That's a nice idea! I'll try to add such assert.

> [@Douglas\_Gregor](#):
>
> Should we design warning suppression at the same time? `-no-warning <group name>` or similar?

I was thinking about this, and it would be easy to implement. I can gather `-[no-]warning-as-error`, `-[no-]warnings-as-errors`, `-suppress-warnings` and `-suppress-warning`(new) together into [`WarningAsErrorRule`](https://github.com/swiftlang/swift/blob/32d599db275de1a5282b1078e6bcc128890aec54/include/swift/Basic/WarningAsErrorRule.h) (renamed to something like `WarningBehaviorRule`) and process them together in the DiagnosticEngine.

> [@Douglas\_Gregor](#):
>
> The only bit of information I know of that I'd like each group to be documented with a snippet of Markdown associated with it (could be in a separate file). Then we can pull these together to document the warning groups in some central way; like [Clang's documentation for diagnostic flags](https://clang.llvm.org/docs/DiagnosticsReference.html#introduction) but with an actual human-written description of "this is the kind of warning you'd see" rather than the diagnostic message diagram's Clang did.

I'll see what I can do. I'd prefer the group and its description to be in the same place. But I'm afraid it would be too awkward to implement with the macro-based approach I used in the `DiagnosticGroups.def` file.

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [July 23, 2024, 9:48pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/7 "2024-07-23T21:48:49Z")

</div>

> [@dmt](#):
>
> > [@Douglas\_Gregor](#):
> >
> > we can have a static assert on the number of warnings that have no group. If you add a warning without a group, it fails and the comment tells you to go put it in a group
> 
> That's a nice idea! I'll try to add such assert.

I think I'd suggest not doing this in your initial PR, or commenting it out, because it'll be a source of conflicts until it lands.

> [@dmt](#):
>
> In case we don't provide support for the `_id:` option we should support the most frequent warnings first.

Yeah. I guess my hope is that we could start with not having this feature, and only add it if we don't make sufficient progress with the warning groups.

> [@dmt](#):
>
> I'll see what I can do. I'd prefer the group and its description to be in the same place. But I'm afraid it would be too awkward to implement with the macro-based approach I used in the `DiagnosticGroups.def` file.

FWIW, there's some prior art and infrastructure here with educational notes.

Doug

---

<div class="post-metadata">

**Author:** ![ktoso](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ktoso/32/44526_2.png) [@ktoso](https://forums.swift.org/u/ktoso)\
**Post date:** [July 24, 2024, 2:37am UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/8 "2024-07-24T02:37:41Z")

</div>

Fantastic to see this 🙂

In server libraries I've maintained I've quite frequently had to [give up on warnings-as-errors](https://github.com/apple/swift-service-context/commit/0c62c5b4601d6c125050b5c3a97f20cce881d32b#diff-89fafc265c1fa601cf2364b20be83308031335fda9467fcf3249d5ec1c0c8172L31) because of maintaining multiple Swift versions and sometimes the warnings flip-flopping between some functions and making it hard to be "clean" on all versions without too much of a hassle.

The other problem we hit frequently is deprecations, even _within_ the same package -- because "new" APIs call "old" APIs sometimes internally, and get deprecation warnings inside the lib itself which we can't solve.

I like the diagnostic "group" approach and also the one-by-one control of `-warning-as-error` / `-no-warning-as-error` and the other flags @Douglas_Gregor proposed. I can definitely see enabling all warnings and selectively disabling a few, or the other way around - enabling a few.

* * *

Thoughts on diagnostic groups:

For deprecations we may want to consider having a group that is about "all" but also allow some `-no-warning-as-error=deprecated-same-module`.

Example:

```swift
Sources/Tracing/TracerProtocol+Legacy.swift:84:11: warning: 'LegacyTracer' is deprecated: renamed to 'Tracer'
extension LegacyTracer {
          ^
Sources/Tracing/TracerProtocol+Legacy.swift:84:11: note: use 'Tracer' instead
extension LegacyTracer {
          ^ ~~~~~~~~~~~
          Tracer

Sources/Tracing/TracerProtocol.swift:25:25: warning: 'LegacyTracer' is deprecated: renamed to 'Tracer'
public protocol Tracer: LegacyTracer {
                        ^
Sources/Tracing/TracerProtocol.swift:25:25: note: use 'Tracer' instead
public protocol Tracer: LegacyTracer {
                        ^ ~~~~~~~~~~~
                        Tracer

```

So e.g. I might want to disable all such warnings in my module, I can't get rid of them after all. But keep being warned about deprecations in other libraries...

Anyway, this goes outside of the scope of this post -- groups, yes! And just that we'll have to figure out good groupings 🙂

👍 I'd be happy to help out grouping up concurrency warnings into some categories and talking this through with the team so we have categories we're happy with. At least concurrency and deprecations could quickly adopt this I think.

❓ One question I thought we should consider: Do we need multiple groups...? like `concurrency` but also `concurrency_some_specific_issue`. I think probably NO may be an okey answer here, just in order to avoid making this too complicated -- if someone wants to disable errors-as-warnings having them to explicitly call out those they care about sounds ok to me. But figured it's a question worth considering as a group.

---

<div class="post-metadata">

**Author:** ![dmt](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmt/32/30830_2.png) [@dmt](https://forums.swift.org/u/dmt)\
**Post date:** [July 24, 2024, 12:02pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/9 "2024-07-24T12:02:43Z")

</div>

> [@ktoso](#):
>
> ❓ One question I thought we should consider: Do we need multiple groups...? like `concurrency` but also `concurrency_some_specific_issue`. I think probably NO may be an okey answer here, just in order to avoid making this too complicated -- if someone wants to disable errors-as-warnings having them to explicitly call out those they care about sounds ok to me. But figured it's a question worth considering as a group.

This is already in the implementation in the PR: Groups can be nested into some other groups. Like [here](https://github.com/swiftlang/swift/pull/74466/files#diff-ad677bf180808d16a1726a4255dbe362641c925f2f256fe24cb7f9c0d691578bR25) the `deprecated` contains the `availability_deprecated` group. So changing the behavior of the `depracated` group will affect all the warnings associated with the `depracated` group itself and all its children.  
It might seem like an overkill, but the `deprecated` group is actually a huge group. It would be a nightmare to list all of the deprecation warnings in the compiler invocation. I didn't want to blow up the initial PR, but I have a complete list of "depracation-related" groups:

> **The list**
>
> ```swift
> GROUP(deprecated, 6.0, 
> availability_deprecated,
> enable_experimental_cxx_interop_flag_deprecated,
> flag_deprecated,
> implicit_bridging_header_imported_from_module_deprecated,
> use_filelists_deprecated,
> darwin_link_objc_deprecated,
> old_driver_deprecated,
> ide_availability_softdeprecated,
> borrowing_in_pattern_matches_deprecated,
> writable_keypath_to_readonly_property_deprecated,
> selector_literal_deprecated,
> invalid_redecl_swift5_deprecated,
> implementation_only_deprecated,
> unlabeled_trailing_closure_deprecated,
> attr_objcImplementation_deprecated,
> witness_deprecated,
> anyobject_class_inheritance_deprecated,
> attr_ApplicationMain_deprecated,
> conditional_conformance_outer_access_deprecated,
> one_pattern_for_several_associated_values_deprecated,
> unsafe_global_actor_deprecated,
> implicitly_unwrapped_optional_deprecated,
> conformance_availability_deprecated,
> hashvalue_implementation_deprecated,
> executor_enqueue_owned_job_implementation_deprecated,
> property_wrapper_wrapperValue_deprecated,
> property_wrapper_init_initialValue_deprecated,
> reordering_tuple_shuffle_deprecated)
> GROUP(availability_deprecated, 6.0)
> GROUP(enable_experimental_cxx_interop_flag_deprecated, 6.0)
> GROUP(flag_deprecated, 6.0)
> GROUP(implicit_bridging_header_imported_from_module_deprecated, 6.0)
> GROUP(use_filelists_deprecated, 6.0)
> GROUP(darwin_link_objc_deprecated, 6.0)
> GROUP(old_driver_deprecated, 6.0)
> GROUP(ide_availability_softdeprecated, 6.0)
> GROUP(borrowing_in_pattern_matches_deprecated, 6.0)
> GROUP(writable_keypath_to_readonly_property_deprecated, 6.0)
> GROUP(selector_literal_deprecated, 6.0)
> GROUP(invalid_redecl_swift5_deprecated, 6.0)
> GROUP(implementation_only_deprecated, 6.0)
> GROUP(unlabeled_trailing_closure_deprecated, 6.0)
> GROUP(attr_objcImplementation_deprecated, 6.0)
> GROUP(witness_deprecated, 6.0)
> GROUP(anyobject_class_inheritance_deprecated, 6.0)
> GROUP(attr_ApplicationMain_deprecated, 6.0)
> GROUP(conditional_conformance_outer_access_deprecated, 6.0)
> GROUP(one_pattern_for_several_associated_values_deprecated, 6.0)
> GROUP(unsafe_global_actor_deprecated, 6.0)
> GROUP(implicitly_unwrapped_optional_deprecated, 6.0)
> GROUP(conformance_availability_deprecated, 6.0)
> GROUP(hashvalue_implementation_deprecated, 6.0)
> GROUP(executor_enqueue_owned_job_implementation_deprecated, 6.0)
> GROUP(property_wrapper_wrapperValue_deprecated, 6.0)
> GROUP(property_wrapper_init_initialValue_deprecated, 6.0)
> GROUP(reordering_tuple_shuffle_deprecated, 6.0)
> 
> ```

Likewise there could be

```swift
GROUP(concurrency, 6.x, concurrency_some_specific_issue)
GROUP(concurrency_some_specific_issue, 6.x)

```

> [@ktoso](#):
>
> For deprecations we may want to consider having a group that is about "all" but also allow some `-no-warning-as-error=deprecated-same-module`.

I think this can be expressed as a group, and doesn't require doing this upfront. We need to add some new warnings corresponding to the existing `conformance_availability_deprecated`, `availability_deprecated` and `availability_deprecated_rename` warnings, and use them when the deprecated function/type is in the same module.  
With that we can build a tree where the `availability_deprecated_same_module` group is nested into the regular `availability_deprecated` group:

```swift
Groups:
GROUP(deprecated, 6.0, 
      availability_deprecated, ...)
GROUP(availability_deprecated, 6.0,
      availability_deprecated_same_module)
GROUP(availability_deprecated_same_module, 6.0)

Warnings:
GROUPED_WARNING(availability_deprecated, availability_deprecated, ...)
GROUPED_WARNING(availability_deprecated_rename, availability_deprecated, ...)
GROUPED_WARNING(conformance_availability_deprecated, availability_deprecated, ...)
GROUPED_WARNING(availability_deprecated_same_module, availability_deprecated_same_module, ...)
GROUPED_WARNING(availability_deprecated_rename_same_module, availability_deprecated_same_module, ...)
GROUPED_WARNING(conformance_availability_deprecated_same_module, availability_deprecated_same_module, ...)

```

---

<div class="post-metadata">

**Author:** ![ktoso](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ktoso/32/44526_2.png) [@ktoso](https://forums.swift.org/u/ktoso)\
**Post date:** [July 24, 2024, 3:03pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/10 "2024-07-24T15:03:43Z")

</div>

> [@dmt](#):
>
> This is already in the implementation in the PR: Groups can be nested into some other groups. Like [here](https://github.com/swiftlang/swift/pull/74466/files#diff-ad677bf180808d16a1726a4255dbe362641c925f2f256fe24cb7f9c0d691578bR25) the `deprecated` contains the `availability_deprecated` group.

Oh even better then! Sorry I didn't check the PR before posting 🙂 That's exactly what I was thinking about, great to see.

> [@dmt](#):
>
> With that we can build a tree where the `availability_deprecated_same_module` group is nested into the regular `availability_deprecated` group:

Sounds good to me! Since we have hierarchies that'll do the job here. I think this works here since one is clearly "wider" -- no deprecation warnings at all, and the other one more specific, within module... We may need to emit them using different IDs but that's doable I think.

This is looking quite neat, thank you @dmt :-)

---

<div class="post-metadata">

**Author:** ![dmt](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmt/32/30830_2.png) [@dmt](https://forums.swift.org/u/dmt)\
**Post date:** [July 24, 2024, 3:42pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/11 "2024-07-24T15:42:13Z")

</div>

> [@ktoso](#):
>
> I think this works here since one is clearly "wider" -- no deprecation warnings at all, and the other one more specific, within module...

Yes, but even when we can't decide which one is wider, we can introduce a new supergroup and include both of them.  
Moreover, a group can have any number of parents, so we can have several supergroups with partially intersecting sets of subgroups.  
For example, some warnings might be related to both the 'concurrency' group and the 'deprecated' group simultaneously. Suppose we want to treat concurrency warnings as errors, but keep deprecation warnings as warnings. This would be achieved with the options: `-warning-as-error concurrency -no-warning-as-error deprecated`.

---

<div class="post-metadata">

**Author:** ![blangmuir](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/blangmuir/32/277_2.png) [@blangmuir](https://forums.swift.org/u/blangmuir)\
**Post date:** [July 24, 2024, 5:02pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/12 "2024-07-24T17:02:02Z")

</div>

@ArtemC What will happen with [no-]warning-as-error options when compiling a Swift interface? Do we get to drop them from the module compilation, or do they apply also when compiling the interface? In clang -W options apply to the module compilation, which causes us to build more module variants.

---

<div class="post-metadata">

**Author:** ![Jason\_Gregori](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jason_gregori/32/15205_2.png) [@Jason\_Gregori](https://forums.swift.org/u/Jason_Gregori)\
**Post date:** [July 30, 2024, 4:39pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/13 "2024-07-30T16:39:32Z")

</div>

This is amazing. +1000.

> [@ktoso](#):
>
> In server libraries I've maintained I've quite frequently had to [give up on warnings-as-errors](https://github.com/apple/swift-service-context/commit/0c62c5b4601d6c125050b5c3a97f20cce881d32b#diff-89fafc265c1fa601cf2364b20be83308031335fda9467fcf3249d5ec1c0c8172L31) because of maintaining multiple Swift versions and sometimes the warnings flip-flopping between some functions and making it hard to be "clean" on all versions without too much of a hassle.

Same here for iOS apps. There are deprecations every year and we can't get to all of them right away. It means turning off warnings-as-errors which leads us to tons and tons of warnings.

---

<div class="post-metadata">

**Author:** ![Alejandro\_Martinez](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alejandro_martinez/32/821_2.png) [@Alejandro\_Martinez](https://forums.swift.org/u/Alejandro_Martinez)\
**Post date:** [July 30, 2024, 5:55pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/14 "2024-07-30T17:55:55Z")

</div>

Any improvements on this aspect will be welcomed.

What I’ve implemented on my team is to not treat them as errors but to block PRs with warnings. For a team it works very well. Crucially this allows is to ignore certain warnings for a period of time while we fix then (usually new iOS or Xcode versions) while at the same time not allowing new ones to be merged. And i think this is the key, we want to allow certain “known warnings “ for a while, but we don’t want to let others slip trough. Errors as warnings is too extreme to be useful on these scenarios.

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [August 2, 2024, 10:22pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/15 "2024-08-02T22:22:26Z")

</div>

> [@blangmuir](#):
>
> @ArtemC What will happen with [no-]warning-as-error options when compiling a Swift interface? Do we get to drop them from the module compilation, or do they apply also when compiling the interface? In clang -W options apply to the module compilation, which causes us to build more module variants.

I think we should drop these from the .swiftinterface so that we don't end up building more module variants.

Doug

---

<div class="post-metadata">

**Author:** ![blangmuir](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/blangmuir/32/277_2.png) [@blangmuir](https://forums.swift.org/u/blangmuir)\
**Post date:** [August 2, 2024, 10:26pm UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/16 "2024-08-02T22:26:23Z")

</div>

@Douglas_Gregor thanks, that was the consensus from others I talked to about this offline as well.

---

<div class="post-metadata">

**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\
**Post date:** [August 3, 2024, 2:27am UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/17 "2024-08-03T02:27:43Z")

</div>

How do warnings-as-errors affect .swiftinterface generation? Are the compiler options written into the .swiftinterface?

---

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [August 3, 2024, 2:34am UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/18 "2024-08-03T02:34:32Z")

</div>

Opinion: Swiftinterfaces are always dependencies and thus swiftinterfaces should never result in warnings. Yes, it’s possible the swiftinterface contains broken code in an inlinable function body and you could conceivably want to fix that, or at least know about it. But in practice that is not the point of swiftinterfaces and it is much simpler if they do not produce warnings. Which, I believe, is the behavior they have today.

---

<div class="post-metadata">

**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\
**Post date:** [August 3, 2024, 3:25am UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/19 "2024-08-03T03:25:26Z")

</div>

I think the recent steps to make the compiler aware of SwiftPM packages might impact that assessment. Other packages are certainly dependencies, but are other modules in the same package true dependencies? If not, should resilient builds affect whether a warning or error is generated by a declaration in a sibling module?

---

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [August 3, 2024, 3:43am UTC](https://forums.swift.org/t/warnings-as-errors-exceptions/72925/20 "2024-08-03T03:43:10Z")

</div>

Warnings for other modules in the same package will be produced when those modules are compiled. Whether or not the warning is emitted only depends on whether the module is compiled, not how it's used.

(Also, swiftinterfaces are only used for binary libraries, so it doesn't actually apply to this case.)

[Next page](https://forums.swift.org/t/warnings-as-errors-exceptions/72925.md?page=2)