Also pass flags to disable SIL optimization passes when merging
modules, since that's completely unnecessary.
An evolution test that used to fail with WMO disabled now passes
with this change.
FIxes <rdar://problem/18913977>.
Also pass flags to disable SIL optimization passes when merging
modules, since that's completely unnecessary.
An evolution test that used to fail with WMO disabled now passes
with this change.
FIxes <rdar://problem/18913977>.
Also pass flags to disable SIL optimization passes when merging
modules, since that's completely unnecessary.
An evolution test that used to fail with WMO disabled now passes
with this change.
FIxes <rdar://problem/18913977>.
If a thunk is referenced from two different functions, the thunk inherits
the fragile attribute from the first function that forced it to be emitted.
This is wrong, in case the first function might not be fragile, while
the second one is. Copying the fragile attribute to an existing thunk when
checking if it has already been emitted is also wrong, because the thunk
might reference another thunk, and so on.
The correct fix is to have SIL serialization serialize the transitive
closure of all fragile functions and thunks referenced from fragile
functions. Re-work SIL function serialization to use a worklist so that
we can do this.
Part of https://bugs.swift.org/browse/SR-267.
A transparent function might be deserialized and inlined into a function
in another module, which would cause problems if the function referenced
local functions.
Previously we would force local functions to have public linkage instead,
which worked, but was not resilient if the body of the transparent
function changed in the module that contained it.
Add a library evolution test ensuring that such a change is resilient
now.
Part of https://bugs.swift.org/browse/SR-267.
I'm going to add some more tests related to @_transparent shortly,
and it is important to verify that bodies of @_transparent functions
are serialized (at least in single-frontend mode, for now).
I realize this test is probably too specific, since in the future
we may sometimes choose not to inline @_transparent functions into
their callers, even if a serialized body is available; but this
will suffice for now.
