...rather than just assuming any initializer without a body that makes it
to SILGen is a memberwise initializer.
In the long term we want SILGen to stop handling these initializers, at
which point we can see if it makes sense to remove this body kind.
No intended functionality change.
Swift SVN r25723
If we have a C function pointer conversion, generate a thunk using the same logic we use for ObjC method thunks, and emit a pointer to that thunk as the C function pointer value. (This works for nongeneric, nonmember functions; generics will additionally need to apply generic parameters within the thunks. Static functions would need to gather the metatype as well.)
Swift SVN r25653
This doesn't allow 'continue' out of an if statement for the same reason we don't
allow it on switch: we'd prefer people to write loops more explicitly.
Swift SVN r25565
Fix a crash in coverage when a while's condition consists only of let
clauses. This degrades to simply not showing the coverage for the
condition in that case for now, since we don't handle Patterns yet.
Swift SVN r25456
Since we weren't assigning region counters until we were emitting
function bodies, we would crash while walking the expressions in
default arguments. This assigns the counters earlier and fixes up the
ASTWalker to expect that.
Swift SVN r25445
If multiple swift files are compiled together, then guessing as to the
file when we emit IR obviously doesn't work. Find the filename when we
generate a function's coverage map and propagate it through SIL.
Swift SVN r25436
Keeping a reference to the function here is dangerous. We only
actually care about the name, so save ourselves a copy of that
instead.
This fixes a crash that seems to happen only when the coverage data is
very large.
Swift SVN r25433
If a non-static 'let' field in a struct has an initializer, its implicitly generated
memberwise initializer should not override that. Handle this by having the memberwise initializer
and default initializer use the initial value of the property instead of an argument to the init.
This would have been a lot easier if sema was synthesizing the ctor bodies instead of SILGen,
but here it is. The missing case is narrow (let (x,y) = (1,2)) and for now we just disable
implicit synthesization of the incorrect case.
Swift SVN r25424
This is also useful in general SIL passes when generating thunks. I am going to
use this in function signature optimization and closure specialization.
Swift SVN r25356
This rearranges code so that the destroy_addr cleanup generated to
deallocate a 'let' stack temporary is generated against the mark_uninitialized
instruction. This allows DI to see it, and nuke it on paths where the let constant
is never assigned.
Swift SVN r25349
Deferring to emitRValue doesn't work for inout parameters. Factor out the code for shuffling arguments in TupleShuffleExprs so we can reuse for ScalarToTuple transformations. Building what amounts to a fake TupleShuffle out of a ScalarToTuple isn't the most elegant solution, but I think it's the lowest-risk approach for the short term. Fixes rdar://problem/19814841.
Swift SVN r25290
This adds the -profile-coverage-mapping option to swift, and teaches
SILGenProfiling to generate mappings from source ranges to counters.
Swift SVN r25266
The problem here was that the _preconditionImplicitlyUnwrappedOptionalHasValue
compiler intrinsic was taking the optional/IUO argument as inout as a performance
optimization, but DI would reject it (in narrow cases, in inits) because the inout
argument looks like a mutation.
We could rework this to take it as an @in argument or something, but it is better
to just define this problem away: the precondition doesn't actually care about the
optional, it is just testing its presence, which SILGen does all the time. Have
SILGen open code the switch_enum and just have the stdlib provide a simpler
_diagnoseUnexpectedNilOptional() to produce the error message.
This avoids the problem completely and produces slightly better -O0 codegen.
Swift SVN r25254
We "convert" unowned to unowned without decaying to the semantic strong type when an unowned reference is captured by a nested closure. If we remove the assert, the codegen looks correct, and external projects walk this code path oblivious to the assertion.
Swift SVN r25248
This adds the -profile-generate flag, which enables LLVM's
instrumentation based profiling. It implements the instrumentation
for basic control flow, such as if statements, loops, and closures.
Swift SVN r25155
rdar://problem/19514920 is caused by a disagreement between IRGen and SILGen about which SILDeclRefs override vtable slots. Factor out the somewhat-hairy code in SILGen to a place IRGen will be able to share it. NFC yet.
Swift SVN r25063
This will have an effect on inlining into thunks.
Currently this flag is set for witness thunks and thunks from function signature optimization.
No change in code generation, yet.
Swift SVN r24998
A stored property of a class may be overridden by a computed one, and a property requirement may be witnessed by a computed property, but rejecting inout aliasing in these cases isn't very helpful. Only reject cases that are definitely computed and will always behave incorrectly. Fixes rdar://problem/19633414.
Swift SVN r24986
The materializeForSet accessor for a `dynamic` property needs to dynamically invoke the getter and setter of the property in order to allow for runtime modification, so it doesn't need to be dynamically dispatched itself. If the property came from an imported ObjC class, then we can't dynamically dispatch it without polluting the selector namespace. Introduce a new 'ForcedStaticDispatch' bit and set it in order to force `dynamic` materializeForSet accessors to be statically dispatched. (They can't be `final` because it's legal to override a dynamic property.) If the property came from ObjC, register materializeForSet as an external declaration so it gets generated by SIL. Fixes rdar://problem/18706056.
Swift SVN r24930
If a grandchild class inherits a thunked override from the child class, use that thunk in the grandchild vtable too. Should round out the fix for rdar://problem/19321484.
Swift SVN r24735
the call instead of during the formal evaluation of the argument.
This is the last major chunk of the semantic changes proposed
in the accessors document. It has two purposes, both related
to the fact that it shortens the duration of the formal access.
First, the change isolates later evaluations (as long as they
precede the call) from the formal access, preventing them from
spuriously seeing unspecified behavior. For example::
foo(&array[0], bar(array))
Here the value passed to bar is a proper copy of 'array',
and if bar() decides to stash it aside, any modifications
to 'array[0]' made by foo() will not spontaneously appear
in the copy. (In contrast, if something caused a copy of
'array' during foo()'s execution, that copy would violate
our formal access rules and would therefore be allowed to
have an arbitrary value at index 0.)
Second, when a mutating access uses a pinning addressor, the
change limits the amount of arbitrary code that falls between
the pin and unpin. For example::
array[0] += countNodes(subtree)
Previously, we would begin the access to array[0] before the
call to countNodes(). To eliminate the pin and unpin, the
optimizer would have needed to prove that countNodes didn't
access the same array. With this change, the call is evaluated
first, and the access instead begins immediately before the call
to +=. Since that operator is easily inlined, it becomes
straightforward to eliminate the pin/unpin.
A number of other changes got bundled up with this in ways that
are hard to tease apart. In particular:
- RValueSource is now ArgumentSource and can now store LValues.
- It is now illegal to use emitRValue to emit an l-value.
- Call argument emission is now smart enough to emit tuple
shuffles itself, applying abstraction patterns in reverse
through the shuffle. It also evaluates varargs elements
directly into the array.
- AllowPlusZero has been split in two. AllowImmediatePlusZero
is useful when you are going to immediately consume the value;
this is good enough to avoid copies/retains when reading a 'var'.
AllowGuaranteedPlusZero is useful when you need a stronger
guarantee, e.g. when arbitrary code might intervene between
evaluation and use; it's still good enough to avoid copies
from a 'let'. The upshot is that we're now a lot smarter
about generally avoiding retains on lets, but we've also
gotten properly paranoid about calling non-mutating methods
on vars.
(Note that you can't necessarily avoid a copy when passing
something in a var to an @in_guaranteed parameter! You
first have to prove that nothing can assign to the var during
the call. That should be easy as long as the var hasn't
escaped, but that does need to be proven first, so we can't
do it in SILGen.)
Swift SVN r24709
If a subclass overrides methods with variance in the optionality of non-class-type members, emit a thunk to handle wrapping more optional parameters or results and force-unwrapping any IUO parameters made non-optional in the derived. For this to be useful, we need IRGen to finally pay attention to SILVTables, but this is a step on the way to fixing rdar://problem/19321484.
Swift SVN r24705
Fixes a crash where we tried to natively vtable dispatch these methods, even when they were in extensions, causing the crash in rdar://problem/18088026.
Swift SVN r24619
rdar://problem/19450969
Undo reverts r24381..24384 with one fix: pull cleanup blocks from the
back of the list. When breaking out of a while loop, an extra release
could over-release a reference.
Swift SVN r24553
Rather than keeping just a "main class" in every module, track the "main file"
that's responsible for producing the module's entry point. This covers both
main source files and files containing classes marked @UIApplicationMain or
@NSApplicationMain.
This should have no functionality change, but is preparation for the next
commit, where we will preserve some of this information in serialization.
Swift SVN r24529
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
It was checking the current function's transparency rather than the
referenced function's transparency.
Fixing this did not seem to have a measureable impact on the performance
of -Onone code.
Fixes rdar://problem/19477711.
Swift SVN r24452
a non-native owner. This is required by Slice, which
will use an ObjC immutable array object as the owner
as long as all the elements are contiguous.
As part of this, I decided it was best to encode the
native requirement in the accessor names. This makes
some of these accessors really long; we can revisit this
if we productize this feature.
Note that pinning addressors still require a native
owner, since pinning as a feature is specific to swift
refcounting.
Swift SVN r24420
Have the ArgumentInitVisitor directly bind argument variables to BB arguments, instead of trying to reuse the InitializationForPattern logic used for general variable bindings. That was a nice idea, but it leads to some ugly edge cases because of the many little ways arguments are different from local variable bindings. By getting rid of the abstraction layers, it's easy for argument binding to bind +0 guaranteed or +1 arguments in place when appropriate, avoiding an r/r pair for "let" bindings. It will also let us eliminate some ugly code from variable binding initialization. Should be NFC aside from some harmless reordering of prolog/epilog variable setup.
Swift SVN r24412
We need this in order to unpin at the correct moment.
Add an assertion that there's a scope active when pushing
an unpin writeback, as well as an assertion to ensure that
we never finish a function with writebacks active.
Swift SVN r24411
