@_preInverseGenerics(except: <inverses>) is an extension of the existing
@_preInverseGenerics attribute that provides selective control over which
inverse requirements are mangled into a declaration's symbol name.
While the bare @_preInverseGenerics strips all inverse constraints
(~Copyable and ~Escapable) from mangling, the 'except:' form allows specific
inverses to be retained. This is needed when a type like Span already had
~Copyable mangled into its ABI-stable symbols and now needs to retroactively
adopt ~Escapable without changing those existing symbols. You can now express
that with `@_preInverseGenerics(except: ~Copyable)` to strip-out every inverse
except ~Copyable to preserve the pre-existing ~Copyable-containing symbols.
It requires the new experimental feature `PreInverseGenericsExcept`.
rdar://176395527
When an `if #unavalable` statement also includes a secondary (non-availability)
condition, the availability scope for the else branch should not be refined.
The else branch can be reached because the secondary condition failed, in which
case the availability condition may not hold.
Resolves rdar://165863221.
Adds a new DynamicMemberLookupSubscriptRequest type for evaluating and
caching the validity of a `SubscriptDecl`'s usage to fulfill a
`@dynamicMemberLookup` requirement for a specific usage.
If the fix-it would remove a range that is followed by a newline and the
remaining text on the line is empty or all whitespace then remove the entire
line. This produces better results when a fix-it removes an attribute that is
written on a line by itself.
If we don't require that experimental feature to be enabled,
users might accidentally publish swiftinterface files using
the attribute, without telling compilers that in order to
consume the swiftinterface file, they need UnderscoreOwned
enabled.
It's a valuable thing to make an error as people may be
publishing interfaces that are hiding the computed property
always.
resolves rdar://174880934
It was originally introduced as an upcoming feature, but there isn't any
precedent for using upcoming features as a way to opt-in to type checking fixes
without an associated Swift Evolution proposal. Rather than using a "feature" to
control this behavior, it would probably be better to offer a way to use
`-Werror` to upgrade these warnings to errors.
Tailor a diagnostic and fix for attributes on aliases, to suggest
moving them to the definition and adding preconcurrency if necessary or
inlining the alias so attribute can be applied.
Fixes rdar://152866923. This logic bug in iteration lead us to
accept Sendable on aliases without actually applying it in some cases.
diagnoseUnclaimed was only incrementing i when the attr was not
claimed. This led to a bug where a claimed attr followed by an unclaimed
attr would not be detected, leading code like `@escaping @Sendable`
on a type alias to be accepted, without @Sendable being represented
on the type, when we intended to diagnose it and bail. Code downstream
behaves like no sendable annotation has been applied.
Loosen availability checking to allow references to a decl that is unavailable
in a broader platform context in contexts which are unavailable in a more
specific platform context. For example, `@available(macOS, unavailable)` decls
should be allowed in `@available(macOSApplicationExtension, unavailable)`
contexts. This enhancement, which has always been desirable but wasn't high
priority, became more important with the introduction of `anyAppleOS`. Some
library authors may replace platform-specific availability annotations with
`anyAppleOS` availability and without this behavior change those attribute
updates would be source breaking.
Test updates assisted by claude.
`-enable-experimental-feature SourceWarningControl` guards the actual *use* of `@warn` attribute, but it did not guard this logic which queries it, which is meant to be general in the absense of the attribute as well.
We are seeing some unintended compile time performance implications from this logic, so for now guard it behind the same experimental feature flag.
Related to rdar://171506799
In some cases, it's useful to allow an availability macro to expand to an empty
availability specification list. Allow developers to express this using macros
that are defined to exactly the string `*`, while continuing to reject `*` in
availability macros that contain other entries.
While '-suppress-warnings' does not fit into the overall model established with command-line controls (-Werror, -Wwarning) and declaration lexical scope controls (@warn), when users specify:
```swift
@warn(DiagGroupID, as: error)
```
They are explicitly opting in to treat certain diagnostic categories as build-halting error conditions and as such they should not longer be silenced by the '-suppress-warnings' flag.
Every time DarwinSDKInfo reads a new key out of SDKSettings, a boatload of test SDKSettings files need to be updated across several repositories and forks and branches. It’s tedious to be careful to update those with real values so that the tests are properly regression testing older SDKs. It’s important to be careful so that the tests are accurate, e.g. to prevent the scenario where DarwinSDKInfo starts reading a new key out of SDKSettings and assumes that it’s always available everywhere, when in reality it was only added a few releases ago and will break with older SDKs. If the test SDKSettings files continue to be updated ad hoc, it’s going to be really easy to copy/paste a default value everywhere, and then clients will see incorrect behaviors with the real SDKs, or even compiler crashes if the key is unconditionally read. Preemptively add all of the maybe-possibly-compiler relevant keys to the test SDKSettings files from the real SDKs so that the test files are an accurate representation and shouldn't need to be touched in the future. Where the test SDKSettings have intentionally doctored data, add a Comments key explaining what is changed from the real SDK, and alter the SDK name with a tag indicating the change.
rdar://168700857