Back off treating local lets of tuple type as "initializable", expanding
on the narrow carve-out from #74133. Without this, we would reject local
lets of tuple type that are initialized piecemeal.
Fixes rdar://135028163.
Back of slightly on when we treat a "let" instance property as immutable
within an initializer, to deal with two newly-introduced source
incompatibilities.
Fixes rdar://129253556.
Stored `let` properties of a struct, class, or actor permit
'inout' modification within the constructor body after they have been
initialized. Tentatively remove this rule, only allowing such `let`
properties to be initialized (assigned to) and not treated as `inout`.
Fixes rdar://127258363.
In preparation for changing the default, explicitly specify the behavior
of all tests that are affected by the choice of behavior for lexical
lifetimes and copy-propagation.
Only issue weak lifetime warnings for users who select object lifetime
optimization. The risk of spurious warnings outweighs the benefits.
Although the warnings are generally useful regardless of the level of
optimization, it isn't really critical to issue them unless the optimizer
aggressively shrinks reference lifetimes.
Fixes rdar://79146338 Xcode warns that "referenced object is
deallocated here" but that object was passed into a method that causes
strong retention)
The DiagnoseLifetimeIssuesPass pass prints a warning if an object is stored to a weak property (or is weakly captured) and destroyed before the property (or captured reference) is ever used again.
This can happen if the programmer relies on the lexical scope to keep an object alive, but copy-propagation can shrink the object's lifetime to its last use.
For example:
func test() {
let k = Klass()
// k is deallocated immediately after the closure capture (a store_weak).
functionWithClosure({ [weak k] in
// crash!
k!.foo()
})
}
Unfortunately this pass can only catch simple cases, but it's better than nothing.
rdar://73910632
Right now the stdlib/overlays can compile against -Onone tests with or without
-enable-ownership-stripping-after-serialization. This will help me to prevent
other work going on from breaking these properties.
This just eliminates -enable-sil-ownership from all target-swift-frontend and
target-swift-emit-silgen RUN lines. Both of those now include
enable-sil-ownership in their expansion.
Compiler passes that intermingle analysis with mutation of the CFG
are fraught with danger. The bug here was that a single AssignInst
could appear twice in DI's Uses list, once as a store use and once
as a load use.
When processing Uses, we would lower AssignInsts on the fly. We would
take care to erase the instruction pointer from the current Use, but
if a subsequent Use *also* referenced the now-deleted AssignInst, we
would crash.
Handle this in the standard way: instead of lowering assignments
right away, just build a list of assignments that we're planning on
lowering and process them all at the very end.
This has the added benefit of simplifying the code, because we no
longer have to work as hard to keep the state of the Uses list
consistent while lowering AssignInsts. The rest of DI should not
care that the lowering got postponed either, since it was already
expected to handle any ordering of elements in the Uses list, so
it could not assume that any particular AssignInst has been lowered.
Fixes <https://bugs.swift.org/browse/SR-9451>.
SE-0155 makes an empty associated value list in an enum element
declaration illegal. Warn about this in legacy Swift mode, and reject
it otherwise. This offers two fixes:
1) Remove the empty associated value list
2) Insert a 'Void' associated value
The only real bug here is that we were looking specifically for `apply`
instructions, so we failed to diagnose `try_apply` calls to mutating
throwing functions on immutable existentials. Fixing this is a
source-compatibility break, but it's clearly in the "obvious bug" category
rather than something we need to emulate. (I found this bug because DI
stopped diagnosing a modification of a property of a `let` existential
when it started being done with `modify`, which of course is called with
`begin_apply`.)
* Make _sanityCheck internal
* Make _debugPrecondition internal
* Make Optional._unsafelyUnwrappedUnchecked internal.
* Make _precondition internal
* Switch Foundation _sanityChecks to assertions
* Update file check tests
* Remove one more _debugPrecondition
* Update Optimization-with-check tests
This fixes a subtle issue where, during single-expression closure type inference, we would ask for the settability of local variables from the outer function's context, leading us to mistakenly consider them mutable inside single-expression closure contexts. DI would catch some but not all violations of the expected semantics here.
By formalizing ReferenceOwnership as a diagnostic argument kind, we get
less boilerplate, better type safety, better output consistency, and
last but not least: future proofing.
When performing a binding/assignment to a weak or unowned variable/property from an initialiser call, emit a warning that the instance will be immediately deallocated.
We can only do this for two reasons:
1. There is a code path that should have gone through the non-exclusively
borrowed self entrypoints, but they were not implemented.
2. We are trying to access self for an argument.
By copying the value, we preserve invariants around ownership and also make it
easy for DI to catch 2 and not blow up in the case of 1. It is better to error
in DI incorrectly, than to hit an unreachable (especially since in non-assert
builds, we don't trap at unreachables and just continue to the next function in
the text segment).
SR-5682
rdar://35402738
Again, since there's no distinction between an enum initializer that
delegates to 'self.init' from one that assigns to 'self', we can remove
the special handling of enum initializers in the 'root self' case.
Now, 'root self' is only used for designated initializers in classes
with no superclass, and struct initializers that perform memberwise
initialization of stored properties.
This regresses some diagnostics, because the logic for delegating
init diagnostics is missing some heuristics present in the root self
case. I will fix this in a subsequent patch.
Previously protocol extension initializers which called 'self.init' were
considered 'delegating', and ones that assign to 'self' were considered
'root'.
Both have the same SIL lowering so the distinction is not useful, and
removing it simplifies some code.
*NOTE* DefiniteInit is still running /after/ ownership is stripped. This is just
making sure that the code we are producing can actually pass the verifier.
rdar://31521023
We cannot model a type variable bound to the ExtInfo of a function
type in the constraint solver, which means we have a hard time
propagating noescape-ness in some cases.
Fixes <rdar://problem/31910280> and <rdar://problem/32409133>.
In all cases the DeclCtx field was supposed to be initialized from the
SILLocation of the function, so we can save one pointer per
SILFunction.
There is one test case change where a different (more precise)
diagnostic is being generated after this change.
Emit a warning for optionals that are implicitly converted to Any, and
add fixits giving options to:
- Add '??' with a default value after
- Force-unwrap the optional with '!'
- Explicitly cast to 'as Any' to silence the warning
This covers diagnostics aspect of SE-0140.
rdar://problem/28196843
Previously, we were only able to detect factory initializers
dispatched through class_method. This didn't work for
factory initializers defined in protocol extensions.
The end result would be that we would strong_release an
uninitialized class instance, which could cause crashes.
Fix DI to correctly release the old instance using
dealloc_partial_ref instead.
Fixes <rdar://problem/27713221>.
