The test enables the Embedded experimental feature, but beside the
compiler support, it also requires loading the stdlib for embedded, but
the test is not marked as such. For configurations that do not build the
embedded stdlibs, this makes the test fail, because the stdlib is not
available. Mark it with the appropriate requires to avoid this problem.
This should not change the results in the swift.org CI because those CI
configurations build the embedded stdlibs by default.
During inlining, some instructions in the caller may be deleted. So
when publishing this best effort list of instructions which were
"changed" during inlining, don't start from a deleted instruction.
Instead just don't publish, as already happens in other cases.
Without actually addressing
```
// TODO: get a list of cloned instructions from the `inlineFunction`
```
this is somewhat better than checking for having reached the end of the
function during the walk because that will result in falsely
broadcasting that some unchanged instructions have changed whereas this
change only results in not broadcasting which is already being done in
some cases (e.g. when a `begin_apply` is immediately followed by an
`end_apply`).
No update is needed for the values they produce. This pass should
really be refactored not to crash on instructions that aren't explicitly
listed or at least not to compile if not every instruction is listed.
rdar://161371112
This function is called in one place in an assertion. It asserts that
the function in question is the stdlib's swap. In language mode 6, the
called value may be wrapped in a `function_conversion_expr` for
`@Sendable`. That's irrelevant for the purposes of this assertion, so
look through such conversions.
rdar://160692694
It's permitted for a `witness_method` instruction to have multiple
type-dependent operands. This can happen when for example when one
local archetype is defined in terms of another.
rdar://159211502
The utility effectively determines whether a value leaks as part of its
work, a subset of the checking done by the ownership verifier. Disable
that checking when the flag that disables the ownership verifier is
passed.
No update is needed for the values they produce. This pass should
really be refactored not to crash on instructions that aren't explicitly
listed or at least not to compile if not every instruction is listed.
rdar://155059418
LifetimeDependenceInsertion inserts mark_dependence on token result of a begin_apply
when it yields a lifetime dependent value. When such a begin_apply gets inlined,
the inliner can crash because of the remaining uses of the token result.
Fix this by inserting mark_dependence on parameter operands that are lifetime dependence sources
and deleting the mark_dependence on token results in the inliner.
Fixes rdar://151568816
We started building iOS sanitizers when switching to
`LLVM_ENABLE_RUNTIMES` to build compiler-rt, and turns out they
currently provide only the arm64 slice.
Addresses rdar://151782340
Apply the MoveOnlyAddressChecker change from
https://github.com/swiftlang/swift/pull/73358 to the
MoveOnly[Value]Checker.
After 7713eef817, before running value
checking, all lifetimes in the function are completed. That doesn't
quite work because lifetime completion expects not to encounter
reborrows or their adjacent phis.
rdar://151325025
This fixes a timeout failure in CI. It looks like that some CI machines are slower than expected.
I could not reproduce this locally. There doesn't seem to be a compile time regression.
Enable walking into `TypeOffsetSizePair`s from an existential into an
archetype. And set the access kind on `open_existential_addr`
instructions which are the sources of rewritten `copy_addr`s to mutable.
rdar://141279635
The test run time jumped from ~200s to ~600s on Linux.
Unfortunately I could not reproduce this locally.
But what I saw is that ARCSequenceOpts is taking 75% of the compile time: rdar://144863155
Let's increase the timeout a bit until we can get rid of ARCSequenceOpts.
rdar://144810758
As the utility runs, new gens may become local: as access scopes are
determined to contain deinit barriers, their `end_access` instructions
become kills; if such an `end_access` occurs in the same block above an
initially-non-local gen, that gen is now local.
Previously, it was asserted that initially-non-local gens would not
encounter when visiting the block backwards from that gen. Iteration
would also _stop_ at the discovered kill, if any. As described above,
the assertion was incorrect.
Stopping at the discovered kill was also incorrect. It's necessary to
continue walking the block after finding such a new kill because the
book-keeping the utility does for which access scopes contain barriers.
Concretely, there are two cases:
(1) It may contain another `end_access` and above it a deinit barrier
which must result in that second scope becoming a deinit barrier.
(2) Some of its predecessors may be in the region, all the access scopes
which are open at the begin of this block must be unioned into the set
of scopes open at each predecessors' end, and more such access scopes
may be discovered above the just-visited `end_access`.
Here, both the assertion failure and the early bailout are fixed by
walking from the indicated initially-non-local gen backwards over the
entire block, regardless of whether a kill was encountered. If a kill
is encountered, it is asserted that the kill is an `end_access` to
account for the case described above.
rdar://139840307
This test forces the usage of macosx-x86_64 and will fail if the x86_64
slice of the stdlib has not been built. Mark it as only running on
macosx-x86_64 to avoid the test failure in that case.
Such destroys mark the lifetime end of their operands along their
availability boundary. They are currently inserted in this test case
by the ClosureLifetimeFixup pass, but in the fullness of time they will
be present for every value which is not explicitly destroyed (that's
what complete OSSA lifetimes is mostly about).
Currently, such destroys are diagnosed by DiagnoseUnreachable. Fix the
diagnostic pass not to diagnose these valid instructions.
rdar://137960229
It turns out that some CI jobs need 5-6 minutes for this test. To give some slack, use a timeout of 10 minutes.
This is a follow-up of https://github.com/swiftlang/swift/pull/76146
No update is needed for the values they produce. This pass should
really be refactored not to crash on instructions that aren't explicitly
listed or at least not to compile if not every instruction is listed.
rdar://133779160