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/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
emitted just the optional buffers, and tested them when evaluated the condition, then
consumed them all (producing the contained value) when the entire condition is true.
This doesn't work with where conditions, because the where condition can use the bound
variables.
The new approach emits the variable bindings as the conditions is emitted, allowing the
bindings to be in scope for where clauses. In addition to this redesign, the implementation
is also somewhat simpler by being a recursive implementation which is (to me at least)
easier to reason about.
multi-pattern where bindings with where clauses should now be fully operational.
Swift SVN r24360
known implementation work required for:
<rdar://problem/19382942> Improve 'if let' to avoid optional pyramid of doom
I want to write some more tests and improve error recovery QoI in the parser,
but I believe it fully works now. Please kick the tires and let me know if
you observe any problems (other than 19432424 which was pre-existing).
Swift SVN r24348
if-let statements (also while and var, of course) that include multiple bindings
and where clauses.
SILGen support still remains, it currently just asserts on the new constructs.
Swift SVN r24239
"isConstant" distinction. This was an irritating bit of redundant state
that was making the code more complicated. Clients of VarLoc really only
care about "has address" and "has box", not whether the VarLoc came from
a let or var (and if they did, they can ask the VarDecl directly). NFC,
just more "yak shaving" as Doug likes to say.
Swift SVN r23869
When we've already established that the optional has a value, using unchecked_take_enum_data_addr to directly extract the enum payload is sufficient and avoids a redundant call and check at -Onone. Keep using the _getOptionalValue stdlib function for checked optional wrapping operations such as "x!", so that the stdlib can remain in control of trap handling policy.
The test/SIL/Serialization failures on the bot seem to be happening sporadically independent of this patch, and I can't reproduce failures in any configuration I've tried.
Swift SVN r22537
When we've already established that the optional has a value, using unchecked_take_enum_data_addr to directly extract the enum payload is sufficient and avoids a redundant call and check at -Onone. Keep using the _getOptionalValue stdlib function for checked optional wrapping operations such as "x!", so that the stdlib can remain in control of trap handling policy.
Swift SVN r22533
A couple reasons for this:
- How 'self' gets cleaned up is dependent on where the failure occurs. If we propagate failure from a class initializer, the failed 'super.init' or 'self.init' has already cleaned up the object, so we only need to deallocate the box. In cases where we fail explicit, we release 'self', which works out because we're only supporting failure with a fully-initialized object for now.
- This lets us set the location info for the cleanup to the AST node that instigated failure, giving better QoI for DI failures (such as failing with a partially-initialized object).
Swift SVN r21505
We don't ever need to destroy_addr the iteration value buffer, because either the for loop exited normally because it's nil, or it exited by 'break' and it contains a stale 'Some' value that was consumed by the loop body. Fixes <rdar://problem/16687672>.
Swift SVN r16942
LabeledStmt that they target: have sema fill this in, and make silgen respect it.
NFC, because this was specifically written to behave the same as before (e.g. no
break out of switches).
Swift SVN r16610
Add an emitIgnoredExpr entrypoint to SILGenFunction that emits an expression, ignoring its result. This isn't an extensive implementation but just tackles the low-hanging fruit of allowing +0 rvalues and not crashing on sudden lvalues, fixing <rdar://problem/16650625>.
Swift SVN r16536
Fix a phase ordering problem: SILGen of a noreturn function doesn't drop an unreachable after the function,
and doing so is problematic for various reasons (all expressions would have to handle their insertion point
vaporizing, and would have to emit unreachable code diagnostics). Instead, run a simple pass that folds
noreturn calls and diagnoses unreachable code, and do it before DI. This prevents DI from seeing false
paths, and rejecting what seems like invalid code.
Swift SVN r14711
- Respond to Doug's code review feedback
- Stop hacking around with scopes and use "emplace" to work around RAII in the inactive config case
- Limit use of StringRef on the front-end, in favor of std::string
- Use ArrayRef rather than SmallVector within IfConfigDecl
- Reorder new property declarations on BraceStmt to prevent unnecessary alignment issues
- Update ParseBraceItems to better capture top-level declarations, rather than using token lookahead
Swift SVN r14306
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
The name Stream didn't seem to be working out as intended; we kept
gravitating back to calling it Generator, which is precedented in other
languages. Also, Stream seems to beg for qualification as Input or
Output. I think we'd like to reserve Stream for things that are more
bulk-character-API-ish.
Swift SVN r13893
Allow IfStmts and WhileStmts to have as their condition either an expression, as usual, or a pattern binding introduced by 'var' or 'let', which will conditionally bind to the value inside an optional. Unlike normal pattern bindings, these bindings require an in-line initializer, which will be required to be Optional type. Parse variable bindings in this position, and type-check them by requiring an Optional on the right-hand side and unwrapping it to form the pattern type. Extend SILGen's lowering of if and while statements to handle conditionally binding variables.
Swift SVN r13146
emission routines use the SGFContext passed in. To help with this and
to help the handshake, add a new "isInContext()" representation to
ManagedValue. This makes the code producing and consuming these more
explicit. NFC.
Swift SVN r12783
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
- constify the Initialization::getAddressOrNull/hasAddress functions.
- Teach the initialization logic that 'let' initializations can be
split into tuple subelements by address (i.e. i
getSubInitializationsForTuple works on them) when the let decl has
a backing memory allocation.
- Teach LetValueInitialization to produce a backing memory object
for address-only tuple arguments, since they are passed as multiple
SILArguments and need some place in memory to reassemble them.
The collection fixes a bad miscompilation where the RValue logic emitted
a temporary (through getSingleValue) which we then accidentally lifetime
extended for the duration of the argument. This led to bad things when
the temporary got destroyed too early.
Thanks to MichaelG for helping narrow down this problem, it initially looked
like a sil optimizer bug.
Swift SVN r12234
This is step 1 of implementing the new Container/Sequence/Stream
protocols. See test/Prototypes/Container.swift for the complete picture
of where this is headed.
Swift SVN r11924
would produce temporary stack allocations. Before the dealloc_stack would get
generated at the end of the foreach sequence, a violation the stack nesting verifier
caught.
Swift SVN r11673
If there's no script-mode file in a module, don't produce a top_level_code SILFunction for it, and don't consider emitting an LLVM global_ctor for it. We should never emit static constructors from user code anymore.
Swift SVN r11644
Instead of hardcoding Builtin.Word to be an alias for Builtin.Int64, make it its own type of abstract pointer width.
- Change BuiltinIntegerType's width representation to accommodate abstract widths.
- In the AST and in SIL, store values of the types as the greatest supported size for the abstract width (64 bits for a pointer).
- Add some type safety to the ([sz]ext|trunc)(OrBitCast)? builtins that they're used appropriately given the upper and lower bounds of the abstract sizes they're working with.
- Now that Builtin.Word is a distinct type, give it its own mangling.
- In IRGen, lower pointer-sized BuiltinIntegerType appropriately for the target, and truncate lowered SIL values if necessary.
Fixes <rdar://problem/15367913>.
Swift SVN r10467
