We have a systemic class of issues where noescape types end up bound to
type variables in places that should not. The existing diagnostic for
this is ad-hoc and duplicated in several places but it doesn't actually
address the root cause of the problem.
For now, I've changed all call sites of createTypeVariable() to set the
new flag. I plan on removing enough occurrences of the flag to replicate
the old diagnostics. Then we can continue to refine this over time.
Looks into the root type of the keypath to find additional members. This
does not currently map the type of the completion to the subscript's
return type.
rdar://49029126
When building the implicit subscript expression, set the "implicit" bit
correctly and pass it through in the indexer so that we get implicit
refernces to the subscript. This would be useful for e.g. searching for
all uses of the dynamic subscript.
Escapingness is a property of the type of a value, not a property of a function
parameter. Having it as a separate parameter flag just meant one more piece of
state that could get out of sync and cause weird problems.
Instead, always look at the noescape bit in a function type as the canonical
source of truth.
This does mean that '@escaping' is now printed in a few diagnostics where it was
not printed before; we can investigate these as separate issues, but it is
correct to print it there because the function types in question are, in fact,
escaping.
Fixes <https://bugs.swift.org/browse/SR-10256>, <rdar://problem/49522774>.
Once the '@escaping' bit is removed from TupleTypeElt, it no longer makes
sense to print argument lists as if they were TupleTypes or ParenTypes,
since function types are '@escaping' by default inside tuples but not
in argument lists.
Instead, print ArrayRef<AnyFunctionType::Param> directly. For now this
introduces some awkward usages of AnyFunctionType::decomposeInput();
these will go away once the AST is changed to represent the argument list
as a list of expressions and not a single tuple expression.
This was partially implemented but the check looked at the lowered
types and not the AST types, and DynamicSelfType is erased at the
top level of a lowered type.
Also use the new mangling for reabstraction thunks with self, to
ensure we don't emit the same symbol with two different lowered
types.
Fixes <https://bugs.swift.org/browse/SR-10309>, <rdar://problem/49703441>.
I am going to use this to ensure some end-to-end tests that do not inline from
the stdlib will work after flipping the switch and stripping ownership after
serialization.
...by coalescing duplicates and dropping conflicts. Both cases can
happen with "expected-error 2 {{...}}": we might get multiple fix-its
providing the same new message, or one message might have diverged
into two, giving us incompatible changes.
Instead of a wholly separate lazyness mechanism for foreign metadata where
the first call to getAddrOfForeignTypeMetadataCandidate() would emit the
metadata, emit it using the lazy metadata mechanism.
This eliminates some code duplication. It also ensures that foreign
metadata is only emitted once per SIL module, and not once per LLVM
module, avoiding duplicate copies that must be ODR'd away in multi-threaded
mode.
This fixes the test case from <rdar://problem/49710077>.
Leave the old flag in as an alias to the new flag, for transition
purposes. Also go ahead and remove the long-deprecated and unused
`emit-interface-path`.
Part of rdar://49359734
When a Swift module built with debug info imports a library without
debug info from a textual interface, the textual interface is
necessary to reconstruct types defined in the library's interface. By
recording the Swift interface files in DWARF dsymutil can collect them
and LLDB can find them.
rdar://problem/49751363
Obj-C subscripts don’t work on class objects, but you can declare class methods with the appropriate names. We don’t want to half-support this. Emit an error if you try to write “@objc class subscript” and test that we don’t import the methods as subscripts.
Okay, strictly we're checking the "signature conformances" of a newly-
declared conformance, but that wouldn't have fit on one line. This is
making sure that we don't have a requirement on an associated type (or
on the conforming type) that can only be satisfied using a conformance
in an implementation-only import.
These also create a dependency on the implementation module, even if
both the type and the protocol are public. As John puts it, a
conformance is basically a declaration that we name as part of another
declaration.
More rdar://problem/48991061
As the complexity of the analysis is more than linear with the number of blocks, disable it for functions with > 2000 basic blocks.
In this case inlining will be less aggressive.
SR-10209
rdar://problem/49522869
This fixes a test involving transitive captures of local functions,
as well as an infinite recursion possible with the old code.
Fixes <rdar://problem/34496304>.
Some diagnostics got worse, but I think the reduction in compiler complexity
is worth it, and copy-and-pasting Swift 2 code is not likely to produce great
results anyway.
Also, this corrects an oversight where we did not reject @pseudogeneric on
function types in AST parsing.
The new pass is based on existing asserts in DiagnoseStaticExclusivity.
They were compiled out in release builds and only checked for captures of
inout parameters. This patch converts the assertions into diagnostics and
adds checks for captures of non-escaping function values.
Unlike the Sema-based checks that this replaces, the new code handles
transitive captures from recursive local functions, which means certain
invalid code that used to compile will now be rejected with an error.
The new analysis also looks at the ultimate usages of a local function
instead of just assuming all local functions are escaping, which fixes
issues where the compiler would reject valid code.
Fixes a bunch of related issues, including:
- <rdar://problem/29403178>
- <https://bugs.swift.org/browse/SR-8546> / <rdar://problem/43355341>
- <https://bugs.swift.org/browse/SR-9043> / <rdar://problem/45511834>
