We now report properties referencing types imported from
implementation-only dependencies in non-library-evolution mode as the
memory layouts of structs and enums may be exposed to clients. Here we
exempt non-open classes from this check as clients hold pointers to
classes which hides the class internal memory layouts. Keep forbidding
it for open classes in order to error early, a client trying to subclass
an open class with such a reference from their property would already
see an error about members not deserializable.
Exclude properties with initial values from the memberwise initializer
if they are less accessible than the most accessible property, up to
`internal`. Introduce a compatibility overload that continues to
include the same properties as before until the next language mode.
This is gated behind the `ExcludePrivateFromMemberwiseInit` feature.
rdar://122416579
Store the original VarDecl in the same map we use for tracking the
original wrapper var for property wrappers. This will allow us to
use the same logic to determine the original var for both.
We need special handling for protocols whose requirement
signature exists but is in a serialized state, as we
cannot run the StructuralRequirementsRequest on such
a protocol as there's no work to be done, effectively.
This is similar to SuppressedAssociatedTypes, but infers
default requirements when primary associated types of
protocols are suppressed. This defaulting for the primary
associated types happens in extensions of the protocol,
along with generic parameters, whenever a source-written
requirement states a conformance requirement for the protocol.
Thus, the current scheme for this defaulting is a simplistic,
driven by source-written requirements, rather than facts
that are inferred while building generic signatures.
Defaults are not expanded for infinitely many associated types.
rdar://135168163
We need to serialize the underlying type substitution map for an
inlinable function. However, there is no reason to deserialize it
eagerly, since doing so can lead to cycles. It is better for
correctness and performance to only deserialize it when needed.
Technically this fixes a regression from #84299, but the actual
problem was there all along, it was just exposed by my change
on a specific project.
Fixes rdar://163301203.
Ensure that calls to SPI operators are only accepted in source files
importing the corresponding SPI group. This applies the same logic to
operators as we do for functions.
rdar://137713966
Implement the @export(implementation) and @export(interface) attributes
to replace @_alwaysEmitIntoClient and @_neverEmitIntoClient. Provide a
warning + Fix-It to start staging out the very-new
@_neverEmitIntoClient. We'll hold off on pushing folks toward
@_alwaysEmitIntoClient for a little longer.
Allow external declaration of global variables via `@_extern(c)`. Such
variables need to have types represented in C (of course), have only
storage (no accessors), and cannot have initializers. At the SIL
level, we use the SIL asmname attribute to get the appropriate C name.
While here, slightly shore up the `@_extern(c)` checking, which should
fix issue #70776 / rdar://153515764.
Don't consider implicitly exposed memory layouts when checking for
usable from inline correctness. That check applies only to memory
layouts marked as exposed explicitly. Consider the implict state only at
the general availability checking.
In non-library-evolution mode, gated behind the CheckImplementationOnly
feature flag, consider structs to be a fragile use site by default,
unless marked `@_implementationOnly`. This prevents them to refer to
restricted imports like implementation-only.
We already reject attempts to reference this for `lazy` properties.
For `lazy` locals let's just not expose it to name lookup to begin
with. This ensures we don't attempt to prematurely kick the interface
type computation for the var, fixing a couple of crashers.
Availability version remapping currently only applies to code built for
visionOS. We plan to introduce more platform kinds and standalone availability
domains that will require version remapping, though, so it's time to
rearchitect and simplify the code to make it easier to generalize.
`AvailabilityDomain` is now responsible for version remapping and much of the
previously duplicated utilities have been consolidated.
Removes the underscored prefixes from the @_section and @_used attributes, making them public as @section and @used respectively. The SymbolLinkageMarkers experimental feature has been removed as these attributes are now part of the standard language. Implemented expression syntactic checking rules per SE-0492.
Major parts:
- Renamed @_section to @section and @_used to @used
- Removed the SymbolLinkageMarkers experimental feature
- Added parsing support for the old underscored names with deprecation warnings
- Updated all tests and examples to use the new attribute names
- Added syntactic validation for @section to align with SE-0492 (reusing the legality checker by @artemcm)
- Changed @DebugDescription macro to explicitly use a tuple type instead of type inferring it, to comply with the expression syntax rules
- Added a testcase for the various allowed and disallowed syntactic forms, `test/ConstValues/SectionSyntactic.swift`.
When defining a C-compatible function with `@c`, we were emitting a
Swift function along with a C-compatible thunk. Stop doing that, and
instead only produce the C-compatible function. All uses of the
function will go through that C interface, just like if the function
were declared in C.
This also applies to `@c @implementation` functions, which are
declared in C but implemented in Swift. It does *not* apply to
`@_cdecl`, which will continue to produce both the Swift function and
C thunk to prevent an ABI break.
Fixes rdar://158888024.
Remove the DeclContext parameter from ResolveMacroRequest, we can now
retrieve the DeclContext either from the CustomAttr or macro expansion
expr/decl directly.
Introduce `DeclAttribute::attachToDecl` which is the now the main
entry point for associating an attribute with a decl. Different
attributes can implement `attachToDeclImpl` to add their custom logic.
Move DifferentiableAttr, DerivativeAttr, CustomAttr, and ABIAttr over
to this new logic.
When importing C++ class template specializations into Swift, we were assigning the owning module to the imported Swift structs inconsistently. For specializations that had a typedef (or a using-decl), we assumed the module that declares the typedef to be the owning module for the specialization. For specializations that do not have a typedef, we assumed the module that declares the class template itself to be the owning module. This changes the behavior to always assume the latter.
rdar://158589803
Introduce CustomAttrOwner that can store either a Decl for an
attached attribute, or a DeclContext for e.g a type or closure
attribute. Store this on CustomAttr such that we can query it from
the name lookup requests.
Record when we encounter a request cycle, and enforce that the outer
step of the cycle also returns the default value. This fixes a couple
of crashers where we were ending up with conflicting values depending
on whether the request was queried from within the cycle or from
outside it.
This helps avoid producing more downstream errors. This changes
`GenericSignature::forInvalid` to produce the same signature as e.g
`<T where T == Undefined>`. This subsumes the need to introduce
conformance requirements for invertible protocols.
