If a function has an error result slot, emit debug info for an artificial
function argument "$error" with indirect storage that holds a pointer
to the error object address.
<rdar://problem/20736999> lldb needs to be able to locate the error return location when stepping out of a function
Swift SVN r28229
All llvm::Functions created during IRGen will have target-cpu and target-features
attributes if they are non-null.
Update testing cases to expect the attribute in function definition.
Add testing case function-target-features.swift to verify target-cpu and
target-features.
rdar://20772331
Swift SVN r28186
Don't project every value witness from the metadata every time we need one; this wastes code size in a way LLVM can't really optimize since it doesn't know the metadata is immutable. The code size wins on the standard library are disappointingly small (stdlib only shrinks by 4KB), but this makes generic IR a lot more compact and easier to read.
Swift SVN r28095
and link it properly. This is needed to embed LLVM bitcode sections
in the standard library and overlays. The linker doesn't support
embedded bitcode and reexport flags (among others).
rdar://problem/20750099
Swift SVN r28052
The Clang importer introduces a number of synthesized conformances for
imported enums (normal, NS_ENUMS, or NS_OPTIONS-based all have the
same issue) that aren't used in most translation units. Rather than go
through the effort of fully checking these conformances and generating
SIL for them always, rely on semantic analysis to force them to be
fully checked when the conformance is required. This cuts down on the
amount of work we need to do for imported enumeration types
considerably. For a simple program consisting of only:
import Foundation
var str = NSString()
My not-entirely-scientific measurements show that:
* Time to parse + type-check is reduced by 34%
* Time to generate SIL is reduced by 50%
* Time to generate IR is reduced by 47%
* SIL output size is reduced by 66%
Fixes rdar://problem/20047340.
Swift SVN r27946
The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
Enable checking for uses of potentially unavailable APIs. There is
a frontend option to disable it: -disable-availability-checking.
This commit updates the SDK overlays with @availability() annotations for the
declarations where the overlay refers to potentially unavailable APIs. It also changes
several tests that refer to potentially unavailable APIs to use either #available()
or @availability annotations.
Swift SVN r27272
The only caveat is that:
1. We do not properly recognize when we have a let binding and we
perform a guaranteed dynamic call. In such a case, we add an extra
retain, release pair around the call. In order to get that case I will
need to refactor some code in Callee. I want to make this change, but
not at the expense of getting the rest of this work in.
2. Some of the protocol witness thunks generated have unnecessary
retains or releases in a similar manner.
But this is a good first step.
I am going to send a large follow up email with all of the relevant results, so
I can let the bots chew on this a little bit.
rdar://19933044
Swift SVN r27241
With this change we will devirtualize in trivial cases where mandatory
inlining has exposed opportunities due to substituting types, for
example substituting a struct type into a witness_method where we can
now easily determine exactly what method will be called.
This makes it possible to use @transparent on struct methods that are
dispatched via generic functions, resulting in the opportunity to emit
diagnostics for these methods as well as eliminate the overhead of the
indirect call.
I saw a handful of 10+% perf improvements at -Onone on our benchmarks.
In theory this should allow us to remove the overloads for ++/-- in
FixedPoint.swift.gyb without a performance penalty (and with the proper
overflow diagnostics), but unfortunately if we were to do so, we would
currently dispatch to functions that lack runtime overflow
checks (rdar://problem/20226526).
Swift SVN r26397
requires pushing the types out. The only interesting one is this diff:
- var (e,f,g:(),h) = MRV()
+ var (e,f,g,h) : (Int, Float, (), Double) = MRV()
... where the type annotation is required to silence the warning about "void type
may be unexpected". This seems perfectly reasonable to me.
Swift SVN r26161
This is mainly for the debugger's use, to set up CompilerInvocations that
match how a particular app was compiled in certain important ways. Today
that's the target (which is also in the binary), the SDK path (which in
the long run should probably be an SDK name), and any random -Xcc options
we need to pass (which we should probably attempt to minimize).
Because there's only one target and SDK per context, and because -Xcc
options can easily conflict, this is only intended to be used once per
CompilerInvocation.
Note that search paths are not covered by this; they are already being
added at the time the module is loaded. See r24545.
Completes rdar://problem/17670778.
Swift SVN r25227
...so that the debugger has the best possible chance of being able to load
the app properly.
We don't do this for frameworks today because we don't want to leak this
information into the public module; once we have a distinction between
"the module that ships with the framework" and "the module that goes into
the debug info" we can do this for frameworks as well.
Part of rdar://problem/17670778
Swift SVN r25204
