When the BitwiseCopyable experimental feature is enabled, infer types to
conform to `_BitwiseCopyable`. The `_BitwiseCopyable` inference broadly
follows the approach taken to infer `Sendable`.
(1) Special types are conformed:
- function types if trivial
- metatypes
- builtin types if trivial
(2) TheTupleType is conditionally conformed.
(3) Nominal types are conformed if:
- non-public or public+fixed-layout
- enum or struct (non-class)
- every field conforms to _BitwiseCopyable
Additionally, check that nominal types which are explicitly conformed to
`_BitwiseCopyable` satisfy the latter two conditions of (3).
For a public, non-fixed-layout type to conform to `_BitwiseCopyable`,
the user must conform the type explicitly.
Finally, verify that conformances correspond to TypeLowering's notion of
triviality to the appropriate extent:
- if a type isn't trivial, it doesn't conform to `_BitwiseCopyable`
unless it's an archetype
- if a type is trivial, it conforms to `_BitwiseCopyable` unless some
field in its layout doesn't conform to `_BitwiseCopyable`, which is
only permitted under certain circumstances (the type has generic
parameters, the type is public non-fixed-layout, the type is a
reference but has ReferenceStorage::Unmanaged, the type is a
ModuleType, etc.)
Obsolete the `-enable-swift3-objc-inference` option and related options by
removing support for inferring `@objc` attributes using Swift 3 rules.
Automated migration from Swift 3 has not been supported by the compiler for
many years.
Allow `@available` on associated types, which can be introduced after
the protocol was introduced. These work precisely how on expects,
because all of the infrastructure for introducing associated types
later on has been available for a while, with two small restrictions:
1. If one uses the primary associated type syntax (e.g., `P<A, B>`),
then the primary associated types must also be available in the
current context.
2. Adding a new associated type to a resilient protocol requires that
associated type to have a default.
Diagnostics about use of potentially unavailable conformances had to be
downgraded to warnings in Swift 5 in order to preserve source compatibility.
These diagnostics should be errors by default in Swift 6.
Resolves rdar://88210812
Warn on imports of the same target module from the same source file when
they have different access-levels. This situation can lead to unexpected
behavior as the compiler will only take into account the most permissive
import.
In the following example, the module Foundation in functionally imported
as public. The `internal` modifier will be ignored. The new diagnostic
reports it as such.
```
public import Foundation
internal import Foundation // warning: module 'Foundation' is imported
as 'public' from the same file; this 'internal' access level will be
ignored
```
This could be an easy mistake to do when using scoped imports where this
diagnostic will also help.
rdar://117855481
Follow the feature flag convention for capitalization and be
consistent with the related NoncopyableGenerics feature.
This is a new feature that no wild Swift code has used it yet:
commit e99ce1cc5d
Author: Kavon Farvardin <kfarvardin@apple.com>
Date: Tue Dec 5 23:25:09 2023
[NCGenerics] add `~Escapable`
Basic implementation of `~Escapable` in the type system.
When a file defining an API is included in two modules, clients calling
that API may get an error about the ambiguity on the duplicated API.
That error is not very helpful when it takes into account the
swiftsourceinfo data and points to the source file instead of the
module. In such a case the notes point twice to the same file and line
of code.
Improve this diagnostic by appending the module name to the notes when a
candidate is found outside of the module.
rdar://116255141
This commit diagnoses cdecl implementations with no matching imported declaration, and also runs them through the ObjCImplementationChecker. Actually testing that the ObjCImplementationChecker diagnoses various failure conditions correctly will be added in a subsequent commit.
The number of errors in a function scope can scale exponentially,
making it hard to root cause and resolve unless we group them into
a single error. Grouping the error diagnostics will considerably
improve the concurrency user experience.
We already need to track the inverses separate from the members in a
ProtocolCompositionType, since inverses aren't real types. Thus, the
only purpose being served by InverseType is to be eliminated by
RequirementLowering when it appears in a conformance requirement.
Instead, we introduce separate type InverseRequirement just to keep
track of which inverses we encounter to facilitate cancelling-out
defaults and ensuring that the inverses are respected after running
the RequirementMachine.
