without a valid SILDebugScope. An assertion in IRGenSIL prevents future
optimizations from regressing in this regard.
Introducing SILBuilderWithScope and SILBuilderwithPostprocess to ease the
transition.
This patch is large, but mostly mechanical.
<rdar://problem/18494573> Swift: Debugger is not stopping at the set breakpoint
Swift SVN r22978
Dramatically improve DI diagnostics in initializers fixing rdar://18414728.
As one small example of the improvement, where an initializer like this:
class Foo {
var path:String? {
return "boo"
}
let aaaaa:String
init() {
if let p1 = path {
used to produce the error: "error: variable 'self.aaaaa' used before being initialized" on path,
we now produce:
x.swift:9:21: error: use of 'self' in property access 'path' before all stored properties are initialized
if let p1 = path {
^
x.swift:6:9: note: 'self.aaaaa' not initialized
let aaaaa:String
^
which is more useful.
Swift SVN r22238
As one small example of the improvement, where an initializer like this:
class Foo {
var path:String? {
return "boo"
}
let aaaaa:String
init() {
if let p1 = path {
used to produce the error: "error: variable 'self.aaaaa' used before being initialized" on path,
we now produce:
x.swift:9:21: error: use of 'self' in property access 'path' before all stored properties are initialized
if let p1 = path {
^
x.swift:6:9: note: 'self.aaaaa' not initialized
let aaaaa:String
^
which is more useful.
Swift SVN r22223
When analyzing a super.init call, we have several instructions involved including an upcast
to the parent type and an applyinst to call super.init. DI was using the location of the upcast
as the point at which it modeled the super.init requirement, not at the point of the applyinst. This
meant that code like:
%x = upcast self to basetype
... stuff ...
apply super.init(%x)
would not catch invalid uses of super in the "stuff" range, because DI thought that super.init was
called at the upcast. Fix this by using the apply as the super.init use, not the upcast.
Swift SVN r22101
initialized to also cover the delegating init case. The location info is pretty awful
on these, but it is more important that we reject these in Beta 1 than it is to be pretty.
Swift SVN r21673
This raises an error for some cases we don't implement correctly yet, though not ones that require super.init or self.init delegation yet.
Swift SVN r21669
self box as well as the address result, so that it picks up retains and releases.
Classify releases as interesting usepoints, and ignore the dealloc_stack.
Similarly, teach the logic in DefiniteInit's conditional destruction stuff to handle
the derived self case (basically, teaching it to special case the self box).
Swift SVN r21622
allowing partially initialized and conditionally uninitialized elements at failure points.
For example, we compile (with optimizations enabled to clean up the branching) this code:
class SomeClass {}
class RootClassWithNontrivialStoredProperties {
let x, y: SomeClass
init?(failAfterPartialInitialization: ()) {
x = SomeClass()
return nil
}
}
into:
sil @...
bb0(%0 : $RootClassWithNontrivialStoredProperties):
%1 = alloc_ref $SomeClass // users: %3, %4
%2 = ref_element_addr %0 : $RootClassWithNontrivialStoredProperties, #RootClassWithNontrivialStoredProperties.x // user: %3
store %1 to %2 : $*SomeClass // id: %3
strong_release %1 : $SomeClass // id: %4
dealloc_ref %0 : $RootClassWithNontrivialStoredProperties // id: %5
%6 = enum $Optional<RootClassWithNontrivialStoredProperties>, #Optional.None!enumelt // user: %7
return %6 : $Optional<RootClassWithNontrivialStoredProperties> // id: %7
}
where the elements of the class are all individually tracked and destroyed if necessary before the class is dealloc'd.
Swift SVN r21621
to track the release as something that needs the class reference to be alive at.
This implements the first piece of that: if all elements of the class are uninitialized
at the time of the release, just turn the release into a dealloc_ref. This is correct
because we know that the value would have had to be fully initialized at a retain, and
though careful construction, this only triggers in the init case.
This allows us to compile this:
class RootClassWithNontrivialStoredProperties {
let x, y: SomeClass
init?(failBeforeInitialization: ()) {
return nil
}
}
into:
sil @_TFC1t39RootClassWithNontrivialStoredPropertiesCfMS0_FT24failBeforeInitializationT__GSqS0__ : $@thin (@thick RootClassWithNontrivialStoredProperties.Type) -> @owned Optional<RootClassWithNontrivialStoredProperties> {
bb0(%0 : $@thick RootClassWithNontrivialStoredProperties.Type):
%1 = alloc_ref $RootClassWithNontrivialStoredProperties // user: %2
dealloc_ref %1 : $RootClassWithNontrivialStoredProperties // id: %2
%3 = enum $Optional<RootClassWithNontrivialStoredProperties>, #Optional.None!enumelt // user: %4
return %3 : $Optional<RootClassWithNontrivialStoredProperties> // id: %4
}
Swift SVN r21620
This is straight-forward, we just unique based on SourceLoc instead of by SILLocation. In cases
where there are multiple SIL Instructions that map to the same file/line/column, the SourceLoc is
a better approximation of what the user cares about.
This wouldn't be super important, except that not having it causes a QoI regression
in a patch I'm working on.
Swift SVN r21619
When DI processes a delegating initializer of an address-only value type, make sure to
mark the copy_addr as an initialization (as it was already doing for an assign
instruction) to fix a miscompilation.
The change to DIMemoryUseCollector.cpp is just to facilitate writing testcases.
Swift SVN r21478
This has two changes:
- In the case when we have an invalid source loc, DI will default to emitting diagnostics
at the enclosing function's location. This makes it more robust in general against
implicitly synthesized code.
- For this diagnostic in particular, emit a tailored message, since super.init is a commonly
synthesized thing.
Swift SVN r20104
DI has two paths for analyzing initialization state: one optimize for solving a single
fact (e.g. the state of a single non-tuple variable in a function), and one that handles
the full generality of multiple states in parallel (e.g. a tuple in a function or the
fields of a struct/class during its init method).
Unfortunately, the dataflow analysis between these two implementations drifted, and I
fixed a bug in the "N" case (rdar://16119509 back in feb) that didn't get fixed in the "1"
case. This reworks all of the dataflow to make the fact propagation more similar between
the two paths and fix the bug along the way.
Swift SVN r17343
The problem here is that the implicitly generated self.init() call is unreachable,
and DCE runs after DI, so DI doesn't know it is unreachable. Fix this by adding a trivial
reachability check before emitting a diagnostic.
This isn't a wholesome solution though, as certain infinite loops and other scenarios that
rely on constant folding won't be handled properly. If anyone runs into this, we could consider
moving constant prop and DCE earlier, though that comes with its own tradeoffs.
Swift SVN r16898
These bits are orthogonal to each other, so combine them into one, and diagnose attempts to produce a type that's both. Spot-fix a bunch of places this revealed by inspection that we would have crashed in SILGen or IRGen if blocks were be handled.
Swift SVN r16088
property in a base class before calling super.init. This is a nice improvement,
and also avoids regressing on QoI when a patch I'm working on finally lands.
Swift SVN r15379
This is a problem whereby the parallel bitvector dataflow stuff in DI was
incorrectly caching speculated results in cycles. In principle, this algorithm
should be reworked to use standard oldschool RPO bitwise dataflow algorithms, but
this patch is a minimal fix and the performance of this code is unlikely to be an issue
anyway.
Swift SVN r14322
There are some straggling references to the context generic param list, but nothing uses the non-interface param or result types anymore!
Swift SVN r13725
Now the pass does not need to know about the pass manager. We also don't have
runOnFunction or runOnModule anymore because the trnasformation knows
which module it is processing. The Pass itself knows how to invalidate the
analysis, based on the injected pass manager that is internal to the
transformation.
Now our DCE transformation looks like this:
class DCE : public SILModuleTransform {
void run() {
performSILDeadCodeElimination(getModule());
invalidateAnalysis(SILAnalysis::InvalidationKind::All);
}
};
Swift SVN r13598
Have SILGen mark all variables bound from pattern bindings without initializers (and *only* ones without initializers) with mark_uninitialized [var] pseudo instructions. On the DI end, *only* consider mark_uninitialized instructions for DI analysis. This has many benefits:
- DI doesn't waste time analyzing locals that are trivially initialized in the original source code.
- DI doesn't try to mangle canonical SIL that has been inlined from transparent functions, which may have been optimized into a form DI isn't written to understand.
While we're here, fix an issue with DCE where it would try to kill unused MarkUninitialized instructions. Although MarkUninitialized has no side effects, it still is semantically important to raw SIL, and can't be killed.
Chris did most of the work here; I just finished updating tests and fixing bugs.
Swift SVN r13247
Lower types for SILDeclRefs from the interface types of their referents, dragging the old type along for the ride so we can still offer the context to clients that haven't been weaned off of it. Make SILFunctionType's interface types and generic signature independent arguments of its Derive the context types of SILFunctionType from the interface types, instead of the other way around. Do a bunch of annoying inseparable work in the AST and IRGen to accommodate the switchover.
Swift SVN r12536
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
When we decide to emit a separate ivar initializer method (via the
Objective-C entry point -.cxx_construct), we no longer initialize the
ivars within the initializer. This only happens for derived classes,
so teach DI about uninitialized 'self' values that require a
super.init call but don't require the ivars to be initialized.
Swift SVN r12240
Builtin.addressof on an uninitialized variable. Before:
t.swift:12:26: error: variable 'self.z' captured by a closure before being initialized
p = UnsafePointer<Y>(Builtin.addressof(&z))
^
After:
t.swift:12:26: error: address of variable 'self.z' taken before it is initialized
p = UnsafePointer<Y>(Builtin.addressof(&z))
^
This resolves rdar://15699057.
Swift SVN r11482
