This is an accepted spelling for the attribute. This commit
also renames the feature flag from `ExtensibleAttribute` to
`NonexhaustiveAttribute` to match the spelling of the attribute.
(cherry picked from commit fe1ae75711)
This attribute controls whether cross-module access to the declaration
needs `@unknown default:` because it's allowed to gain new cases even
if the module is non-resilient.
(cherry picked from commit a0ae93d3a8)
Explanation: C++ interop synthesizes certain forwarding functions in an
_ObjC module. This confuses MemberImportVisibility. This patch adds
logic to work this around by keeping a mapping between the synthesized
and the original function and looks up where the synthesized functions
belong to based on the original functions' parent module.
Scope: C++ forward interop when MemberImportVisibility is enabled.
Issues: rdar://154887575
Original PRs: #82840
Risk: Low, a narrow change makes getModuleContextForNameLookupForCxxDecl more
precise, and it is only used with MemberImportVisibility.
Testing: Added a compiler test.
Reviewers: @egorzhdan, @tshortli, @hnrklssn
If we fail to resolve the value type for a value generic parameter,
previously we would have returned a null Type, causing crashes
downstream. Instead, return an ErrorType, leaving a null Type for
cases where the generic parameter isn't a value generic at all.
rdar://154856417
- **Explanation**: USR mangling can include an extension context infix
(`AAE`) when an extended type uses `@_originallyDefinedIn` on platforms
other than the active one. This adds a check for the
`RespectOriginallyDefinedIn` flag when checking extension decls against
their extended type.
- **Scope**: Changes USR mangling in these situations so that USRs are
the same for the same code regardless of platform.
- **Issues**: rdar://152598492
- **Original PRs**: https://github.com/swiftlang/swift/pull/82348
- **Risk**: Low. The change is limited to situations where the name
mangler is already disrespecting the alternate module name, and only
additionally turns on that flag for any USR mangling.
- **Testing**: Automated tests
- **Reviewers**: @edymtt @augusto2112
Explanation: Shared references imported from C++ were not considered
safe. This is a widely used feature and this fix is blocking the users
from adopting strictly memory safe Swift.
Issue: rdar://151039766
Risk: Low, the fix only changes what declarations are considered safe.
Testing: Regression test added.
Original PR: #82203
Reviewer: @egorzhdan @fahadnayyar
Initially this declaration is going to be used to determine
per-file default actor isolation i.e. `using @MainActor` and
`using nonisolated` but it could be extended to support other
file-global settings in the future.
(cherry picked from commit aabfebec03)
Due to a bug in how macros on nodes imported from clang are evaluated,
their function body is not always type checked. This forces type
checking before silgen of a macro originating on a node imported from
clang, to prevent crashing in silgen.
rdar://150940383
(cherry picked from commit efd70b1f54)
Similarly to how https://github.com/swiftlang/swift/pull/70564 configures 'ClangImporter's 'CodeGenerator' using Swift's compilation target triple, we must use the versioned version of the 'isWeakImported' query to determine linkage for imported Clang symbols.
Don't bind references to storage to use (new ABI) coroutine accessors
unless they're guaranteed to be available. For example, when building
against a resilient module that has coroutine accessors, they can only
be used if the deployment target is >= the version of Swift that
includes the feature.
rdar://148783895
Several callers of `AbstractStorageDecl::getAccessStrategy` only cared
about whether the the access would be via physical storage. Before
adding more arguments to `getAccessStrategy` for which such callers
would have to pass a sentinel value, add a convenience method for this.
Introduce `PatternBindingCaptureInfoRequest`, and kick it after
contextualizing a property initializer. This ensures it gets run
for stored properties added by macro expansions.
rdar://143429551
It doesn't seem like this is necessary anymore since we no longer
clone OverrideAttrs when checking overrides (except when
invalidating). Moreover, it's now actively wrong since accessors
introduced by macro expansions may be in different buffers than their
their storage, so checking `isBeforeInBuffer` will non-deterministically
result in the wrong source range.
The last step in building a generic signature is to sort the requirements.
Requirements are sorted by comparing their subject types. If two
requirements have the same subject type, which can only happen with
conformance requirements, we break the tie by comparing protocol
declarations.
We compare protocol declarations using TypeDecl::compare(), which is a
shortlex order on the components of the fully qualified name of a
protocol (eg, Swift.Sequence, etc.)
While this order is part of the ABI, it has not been updated over the
years for several important changes:
- It did not handle module aliases; if we import a module via an
alias, we should use the real module name to compare protocols, and
not the aliased name. This produced inconsistent results if the
same module was imported under different names, which can happen
with module interface files that use module aliases.
- It did not handle the -module-abi-name flag. Changing the ABI name
of a module changes how we mangle protocol names, and the order
should match the mangling.
This change fixes the first case only. The second requires more
careful staging, because of _Concurrency and CompilerSwiftSyntax.
Fixes rdar://147441890.
Rather than looking at their DeclContext, look at the location of
their storage. This allows us to differentiate accessors added by
macro expansions vs accessors that are attached to storage that's
in a macro expansion.
ABI-only declarations now inherit access control modifiers like `public` or `private(set)`, as well as `@usableFromInline` and `@_spi`, from their API counterpart. This means these attributes and modifiers don’t need to be specified in an `@abi` attribute.
Very few tests because we aren’t yet enforcing the absence of these attributes.
ABI-only declarations now query their API counterpart for things like `isObjC()`, their ObjC name, dynamic status, etc. This means that `@objc` and friends can simply be omitted from an `@abi` attribute.
No tests in this commit since attribute checking hasn’t landed yet.
