When deserializing an opaque type xref inside an extension context, we were looking
incorrectly in the base module of the type being extended, rather than in the module
of the extension, where the opaque type would really be. Fixes rdar://problem/51775500.
This includes a small refactoring of OpaqueTypeDecl deserialization to break the inevitable
cycle between deserializing the namingDecl, and the namingDecl turning around and re-
deserializing its opaque return type. This is NFC but avoids some unnecessary work.
Check the availability of decls that declare an opaque return type to ensure they deploy to a
runtime that supports opaque types.
rdar://problem/50731151
We do not consider inout_aliasable to be "truly mutating" since today it is just
used as a way to mark a captured argument and not that something truly has
mutating semantics. The reason why this is safe is that the typechecker
guarantees that if our value was immutable, then the use in the closure must be
immutable as well.
In a future SIL, we want to remove Inout_Aliasable in favor of just using
inout/in_guaranteed using the capture info from the type checker.
rdar://50212579
Specifically, if we had a value that was consumed in the same block that it was
produced in, we ignored use-after-frees in subsequent blocks. We did check for
use-after-frees in the same block though. The general case was handled
correctly, this was just an incorrect early exit.
On master, this only found one problem (namely the one fixed in:
14d39c0cf9). I do not expect this corner case to
have more impact after cherry-picking to 5.1.
rdar://49794321
I also removed the -verify-sil-ownership flag in favor of a disable flag
-disable-sil-ownership-verifier. I used this on only two tests that still need
work to get them to pass with ownership, but whose problems are well understood,
small corner cases. I am going to fix them in follow on commits. I detail them
below:
1. SILOptimizer/definite_init_inout_super_init.swift. This is a test case where
DI is supposed to error. The only problem is that we crash before we error since
the code emitting by SILGen to trigger this error does not pass ownership
invariants. I have spoken with JoeG about this and he suggested that I fix this
earlier in the compiler. Since we do not run the ownership verifier without
asserts enabled, this should not affect compiler users. Given that it has
triggered DI errors previously I think it is safe to disable ownership here.
2. PrintAsObjC/extensions.swift. In this case, the signature generated by type
lowering for one of the thunks here uses an unsafe +0 return value instead of
doing an autorelease return. The ownership checker rightly flags this leak. This
is going to require either an AST level change or a change to TypeLowering. I
think it is safe to turn this off since it is such a corner case that it was
found by a test that has nothing to do with it.
rdar://43398898
I have been meaning to do this change for a minute, but kept on putting it off.
This describes what is actually happening and is a better name for the option.
We are already doing this for most of the target-swift-frontend ones. In a
subsequent commit, I am going to remove the redundant ones.
NOTE: On Darwin, I have not enabled it on the %target-swift-frontend mock SDK
commands. I ran into an issue with one of the PrintAsObjC tests that I am still
tracking down. I would rather just get this turned on to prevent further
regressions.
I also updated a few tests that needed some small tweaks to pass
this. Specifically:
1. Some parser tests needed some extra ossa insts to pass the verifier. This
doesn't effect what they actually test.
2. IRGen tests that should never have processed ossa directly. Today, we are
working towards a world where IRGen never processes [ossa] directly. Instead we
lower first. If/when that changes, we should add back in specific [ossa] tests.
3. A singular SILOptimizer definite init test case where the ownership verifier
fails due to a case which DI already flags as illegal (we just crash earlier). I
am going to look into fixing that by putting in errors in the typechecker or in
SILGen (not sure yet). I changed it to use target-swiftc_driver which does not
have ownership verification enabled.
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
Using an anonymous union in KeyPathPatternComponent instead of the weird void * in SetterAndIdKind
Added TupleElement kind to KeyPathComponentKindEncoding
Written basic SIL keypath serialization tests
Deleted or edited some old Swift-level tuple key path tests
Specifically:
bb0:
br bb1
bb1:
cond_br ..., bb2, bb3
bb2:
br bb1
bb3:
return
What would happen in this case is that we wouldn't revisit bb1 after we found
the double consume to grab the leak (and would early exit as well). So we would
not insert a destroy for the out of loop value causing a leak from the
perspective of the ownership checker. This was due to us early exiting and also
due to us not revisiting bb1 after we went around the backedge from bb2 ->
bb1. Now what we do instead is if we catch a double consume in a block we have
already visited, we check if we haven't visited any of that block's
successors. If we haven't, we add that to the list of successors we need to
visit.
We only ever use this in TBDGen and interface printing, and we only ever
generate TBD files or print interfaces for declarations in primary files,
so let's avoid unnecessary work in validateDecl().
Eventually we want validateDecl() to be replaced with a getInterfaceType()
request, so adding new attributes in this path (or other side effects in
general) is a big no-no.
I discovered this while testing the new commit, since it results in fewer
witness tables getting pre-declared.
There was a SIL test that relied on the old behavior; I'm going to explicitly
declare those witness tables as public_external to preserve behavior.
Note that SILModule::lookUpWitnessTable() only attempts to deserialize
the witness table if we already have a declaration. In the
SILLinkerVisitor, we would call lookUpWitnessTable(), see if it returned
null, create a declaration, and if deserializeLazily is true, we would
call lookUpWitnessTable() again; this time, there was a declaration, and
we would deserialize the witness table.
However, if there was already a witness table declaration when we first
called lookUpWitnessTable(), we would trigger deserialization, even if
deserializeLazily is false.
Change the first call to pass false.
I had to update a couple of tests; I believe they were already somewhat
nonsensical.
