Opaque result type archetypes can involve type variables, which
then get introduced into GenericSignatureBuilders and the
generated GenericSignatures. Allocate them in the proper arena
So we don’t end up with use-after-free errors.
Fixes rdar://problem/50309503.
This commit adds a new type DynamicLookupInfo that provides information
about how a dynamic member lookup found a particular Decl. This is
needed to correctly handle KeyPath dynamic member lookups, but for now
just plumb it through everywhere.
...since they're part of the run-time representation. Not having this
meant that someone compiling against an interface would miscompile
uses of @objc enums defined in that interface!
rdar://problem/50410541
- In Sema, don't traverse nested declarations while deducing the opaque return type. This would
cause returns inside nested functions to clobber the return type of the outer function.
- In IRGen, walk the list of opaque return types we keep in the SourceFile already for type
reconstruction, instead of trying to visit them ad-hoc as part of walking the AST, since
IRGen doesn't normally walk the bodies of function decls directly.
Fixes rdar://problem/50459091
Way back in Swift 1 I was trying to draw a distinction between
"overlays", separate libraries that added Swift content to an existing
Objective-C framework, and "the Swift part of a mixed-source
framework", even though they're implemented in almost exactly the same
way. "Adapter module" was the term that covered both of those. In
practice, however, no one knew what "adapter" meant. Bring an end to
this confusion by just using "overlay" within the compiler even for
the mixed-source framework case.
No intended functionality change.
Keep track of information that led the module interface loader to reject loading a compiled module, if it needed to fall back to compiling an interface.
rdar://47792754
KeyPath dynamic member lookup is limited to what key path itself
could do, so let's detect and diagnose invalid references just
like we do for regular key path expressions.
Resolves: rdar://problem/50376224
Detect difference in escapiness while matching function types
in the solver and record a fix that suggests to add @escaping
attribute where appropriate.
Also emit a tailored diagnostic when non-escaping parameter
type is used as a type of a generic parameter.
When a property delegate type has a default initializer, use that to
implicitly initialize properties that use that delegate and do not have
their own initializers. For example, this would allow (e.g.), delegate
types like the DelayedImmutable and DelayedMutable examples to drop
the explicit initialization, e.g.,
```
@DelayedMutable var foo: Int
```
would be implicitly initialized via
```
$foo = DelayedMutable()
```
This is a simplistic implementation that does not yet propertly handle
definite initialization.
Fixes rdar://problem/50266039.
Module interfaces don't yet carry enough information to correctly
describe the binary interface of a module compiled without
-enable-library-evolution, but we don't want to make this an error
because that would make it harder to work towards getting it in the
future.
If the project ever drops Swift 4 mode or Swift 4.2 mode, that would
break modules using those modes in their interface, so put an
unsilenceable warning in for using those modes to nudge interface
emitters to Swift 5.
rdar://problem/47792595
Enhance call-argument matching to reject trailing closures that match up
with parameters that cannot accept closures at all.
Fixes rdar://problem/50362170.
This does several different things to improve how platforms are described in availability diagnostics:
• Mentions the platform in diagnostics for platform-specific @available(unavailable) attributes.
• Replaces “OS X” with “macOS”.
• Replaces “fooOS application extension” with “application extensions for fooOS”.
• Replaces “on fooOS” with “in fooOS”.
Fixes <rdar://problem/49963341>.
The determination of whether a property is memberwise-initialized is
somewhat confused for properties that have synthesized backing properties.
Some clients (Sema/Index) want to see the declared properties, while others
(SILGen) want to see the backing stored properties. Add a flag to
`VarDecl::isMemberwiseInitialized()` to capture this variation.
New diagnostic framework can already identify contextual failures
related to opaque return types, `RequirementFailure` just needs
to get adjusted to identify correct affected declaration and provide
tailored diagnostic.
Resolves: rdar://problem/49582531
This utility was defined in Sema, used in Sema and Index, declared in
two headers, and semi- copy-pasted into SILGen. Pull it into
VarDecl::isMemberwiseInitialized() and use it consistently.
