Since the introduction of custom attributes (as part of property
wrappers), we've modeled the context of expressions within these
attributes as PatternBindingInitializers. These
PatternBindingInitializers would get wired in to the variable
declarations they apply to, establishing the appropriate declaration
context hierarchy. This worked because property wrappers only every
applied to---you guessed it!---properties, so the
PatternBindingInitializer would always get filled in.
When custom attributes were extended to apply to anything for the
purposes of macros, the use of PatternBindingInitializer became less
appropriate. Specifically, the binding declaration would never get
filled in (it's always NULL), so any place in the compiler that
accesses the binding might have to deal with it being NULL, which is a
new requirement. Few did, crashes ensued.
Rather than continue to play whack-a-mole with the abused
PatternBindingInitializer, introduce a new CustomAttributeInitializer
to model the context of custom attribute arguments. When the
attributes are assigned to a declaration that has a
PatternBindingInitializer, we reparent this new initializer to the
PatternBindingInitializer. This helps separate out the logic for
custom attributes vs. actual initializers.
Fixes https://github.com/swiftlang/swift/issues/76409 / rdar://136997841
If a (trailing) closure is determined to be an extraneous argument
for one of the overload choices it needs to be marked as hole as
eagerly as possible and prevented from being resolved because
otherwise it's going to be disconnected from the rest of the
constraint system and resolution might not be able to find all of
the referenced variables. This could result either in crashes
or superfluous diagnostics.
Resolves: rdar://141012049
When compiling with C++ interop enabled, we enable extra safety checks to prevent library authors from accidentally exposing ABI-fragile C++ symbols in resilient Swift interfaces.
The heuristic we use is overly strict, and it prevents the compiler from being able to typecheck various modules from their interfaces when C++ interop is enabled. Darwin and System are two of such modules.
The underlying challenge is that there isn't a good distinction between C structs and C++ structs: whenever parsing a header file in C++ language mode, Clang assumes that every struct is a C++ struct.
This relaxes the heuristic to allow exposing C-like structs in resilient interfaces.
rdar://140203932
When a decl that has properties with accessors (`get`, `set`, `willSet`, `didSet`, `subscript()`, etc) is nested inside another type, those accessor implementations aren't playground-transformed.
The reason is that the playground transform uses an `ASTWalker` to get to the top-level structure, but then once it’s inside a type, it does directly nested `transformDecl()` calls. And that inner check is missing a case for accessors.
This change adds an else-clause that checks if the declaration is a `AbstractVarDecl`, and if so, calls `transformDecl()` on each accessor.
It's unfortunate that the playground transform reaches decls in two different ways (using an `ASTWalker` to get to the top-level decls but then using directly nested calls below). That issue seems to be worth resolving at some point (perhaps by using the `ASTWalker` for the whole traversal?)... but that would be a larger change requiring more thought, and so the missing results being fixed here are worth addressing with a safer short-term fix.
rdar://139656464
This query's functionality was not useful enough to be exposed on `Decl` and
cached in the request evaluator. Instead, just share a local implementation of
it in `TypeCheckAttr.cpp`.
Avoid wrapping parameters in the function reference
for compound applies, and make sure we consult
the parameter label in the compound name if it's
present to determine whether to match using the
projected value or not. This matches the existing
logic in `unwrapPropertyWrapperParameterTypes`.
There are a bunch of AST nodes that can have
associated DeclNameLocs, make sure we cover them
all. I don't think this makes a difference for
`unwrapPropertyWrapperParameterTypes` since the
extra cases should be invalid, but for cursor info
it ensures we handle UnresolvedMemberExprs.
Just because the type of the initializer expression is an opaque return type,
does not mean it is the opaque return type *for the variable being initialized*.
It looks like there is a bit of duplicated logic and layering violations going
on so I only fixed one caller of openOpaqueType(). This addresses the test case
in the issue. For the remaining calls I added FIXMEs to investigate what is
going on.
Fixes https://github.com/swiftlang/swift/issues/73245.
Fixes rdar://127180656.
The problem here is when wrapping a type that has constructors and destructors inside another type.
The reason is that the playground transform uses an `ASTWalker` to get to the top-level structure, but then once it’s inside a type, it does directly nested transformDecl() calls. And that inner check was for too narrow of a type.
The problem in this case was that the `dyn_cast<FuncDecl>(D)` was too narrow and didn’t include constructors/destructors. We want `dyn_cast<AbstractFunctionDecl>(D)`.
We should probably resolve this duality (using an `ASTWalker` to get to the top-level decls but then using directly nested calls below) at some point, but that’s a larger change, and so the specific problem covered by this commit is worth addressing with this safer short-term fix.
Changes:
- change a `dyn_cast<FuncDecl>` to a `dyn_cast<AbstractFunctionDecl>` in PlaygroundTransform.cpp
- add a unit test nested init and deinit (this test also tests the unnested case)
rdar://137316110
`dumpActiveScopeChanges` is used as part of `-debug-constraints`
and could be overwhelming if there are a lot of changes in the scope
because it prints every change including binding inference from
every applicable constraint.
These changes make `dumpActiveScopeChanges` more of summary of
what happened with type variables and constraints so far which
is much easier to navigate while debugging.
This was previously an artificial limitation of the
FunctionRefKind representation, there's no reason
we shouldn't support IUOs for functions referenced
using a compound name.
Many APIs using nonescapable types would like to vend interior pointers to their
parameter bindings, but this isn't normally always possible because of representation
changes the caller may do around the call, such as moving the value in or out of memory,
bridging or reabstracting it, etc. `@_addressable` forces the corresponding parameter
to be passed indirectly in memory, in its maximally-abstracted representation.
[TODO] If return values have a lifetime dependency on this parameter, the caller must
keep this in-memory representation alive for the duration of the dependent value's
lifetime.
Also remove the underlying `SemanticUnavailableAttrRequest`, which used memory
very inefficiently in order to cache a detailed answer to what was usually a
much simpler question.
The only remaining use of `Decl::getSemanticUnavailableAttr()` that actually
needed to locate the semantic attribute making a declaration unavailable was in
`TypeCheckAttr.cpp`. The implementation of the request could just be used
directly in that one location. The other remaining callers only needed to know
if the decl was unavailable or not, which there are simpler queries for.
# Please enter the commit message for your changes. Lines starting
In terms of the test suite the only difference is that we allow for non-Sendable
types to be returned from nonisolated functions. This is safe due to the rules
of rbi. We do still error when we return non-Sendable functions across isolation
boundaries though.
The reason that I am doing this now is that I am implementing a prototype that
allows for nonisolated functions to inherit isolation from their caller. This
would have required me to implement support both in Sema for results and
arguments in SIL. Rather than implement results in Sema, I just finished the
work of transitioning the result checking out of Sema and into SIL. The actual
prototype will land in a subsequent change.
rdar://127477211
If a Swift module built with library evolution enabled is an overlay of a C++ module, allow referring to the non-resilient C++ symbols from the Swift code.
Overlays are usually built and shipped along with the C/C++ modules, so library evolution is less of a concern there. A developer providing a Swift overlay for a C++ library would expect to be able to refer to the symbols from the C++ library within the overlay.
