The previous code would always remove the view on exit, even if it had not previously added it (default: case of the switch)
In simple cases, this didn't really matter, but if you caused the logger to be reinvoked on self in a loop, then you would end up removing the view before you were done looping over it, and eventually run out of stack space
Fixes rdar://19558026
Swift SVN r24737
Previously the "as" keyword could either represent coercion or or forced
downcasting. This change separates the two notions. "as" now only means
type conversion, while the new "as!" operator is used to perform forced
downcasting. If a program uses "as" where "as!" is called for, we emit a
diagnostic and fixit.
Internally, this change removes the UnresolvedCheckedCastExpr class, in
favor of directly instantiating CoerceExpr when parsing the "as"
operator, and ForcedCheckedCastExpr when parsing the "as!" operator.
Swift SVN r24253
_preconditionFailure()s. Some of these checks are clearly redundant (for
example, the check of array subscript), but since we have no tests for
these traps (and reflection is not fast in general), I prefer to keep this
transformation as straightforward as possible.
Swift SVN r20971
Move all of the information about API notes into the "apinotes"
subdirectory, which specifies the API notes that it provides. The
organization is such that "apinotes" can become its own separate
repository, and the compiler build will pick up those API notes that
are available and build them along with the overlays.
Swift SVN r20406
There's no meaningful way in which these methods are public, since they
can't be accessed through any value of the type
<rdar://problem/17647878>
Swift SVN r20224
.apinotes files provide API annotations alongside the Swift overlays
for Objective-C modules, and will be handled by the Clang
importer. Start generating these files from the current in-compiler
source (KnownObjCMethods.def).
The eventual goal is to switch from KnownObjCMethods.def to the
currently-being-defined textual format for API notes, and to replace
the silly swift-ide-test invocations with a Swift driver mode.
Swift SVN r20085
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
However, a view can ask to be redrawn by setting its needsDisplay flag to true
When this happens in a playground, the
self.needsDisplay = true line
forces the view to be logged - logging the view forces it to be redrawn, and unless there's a way out that does not force-redraw, this ends up being an endless loop & of course at some point we run out of stack, and "random" crashes ensue
Add a set of views currently being logged and add/remove views as needed to ensure we don't try to actively log the same view twice
Since UI drawing can only happen on the main thread, if you try to concurrently log views from different threads, you already have a problem, so this can be treated as a single-threaded problem
Fixes <rdar://problem/17027976>
Swift SVN r19730
COMPILE_FLAGS is currently used for two purposes:
- For any target library, add the appropriate Swift optimization flags. This eliminates the add_swift_optimization_flags boilerplate and makes these flags work for all library variants
- For the runtime, pass the appropriate define down when SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS is set, so that all library variants get this setting.
Swift SVN r19444
We haven't been advertising this syntax much, and it's closure form
was completely broken anyway, so don't jump through hoops to provide
great Fix-Its here.
Swift SVN r19277
Keep calm: remember that the standard library has many more public exports
than the average target, and that this contains ALL of them at once.
I also deliberately tried to tag nearly every top-level decl, even if that
was just to explicitly mark things @internal, to make sure I didn't miss
something.
This does export more than we might want to, mostly for protocol conformance
reasons, along with our simple-but-limiting typealias rule. I tried to also
mark things private where possible, but it's really going to be up to the
standard library owners to get this right. This is also only validated
against top-level access control; I haven't fully tested against member-level
access control yet, and none of our semantic restrictions are in place.
Along the way I also noticed bits of stdlib cruft; to keep this patch
understandable, I didn't change any of them.
Swift SVN r19145
There's a bit of a reshuffle of the ExplicitCastExpr subclasses:
- The existing ConditionalCheckedCastExpr expression node now represents
"as?".
- A new ForcedCheckedCastExpr node represents "as" when it is a
downcast.
- CoerceExpr represents "as" when it is a coercion.
- A new UnresolvedCheckedCastExpr node describes "as" before it has
been type-checked down to ForcedCheckedCastExpr or CoerceExpr. This
wasn't a strictly necessary change, but it helps us detangle what's
going on.
There are a few new diagnostics to help users avoid getting bitten by
as/as? mistakes:
- Custom errors when a forced downcast (as) is used as the operand
of postfix '!' or '?', with Fix-Its to remove the '!' or make the
downcast conditional (with as?), respectively.
- A warning when a forced downcast is injected into an optional,
with a suggestion to use a conditional downcast.
- A new error when the postfix '!' is used for a contextual
downcast, with a Fix-It to replace it with "as T" with the
contextual type T.
Lots of test updates, none of which felt like regressions. The new
tests are in test/expr/cast/optionals.swift.
Addresses <rdar://problem/17000058>
Swift SVN r18556
assert() and fatalError()
These functions are meant to be used in user code. They are enabled in debug
mode and disabled in release or fast mode.
_precondition() and _preconditionFailure()
These functions are meant to be used in library code to check preconditions at
the api boundry. They are enabled in debug mode (with a verbose message) and
release mode (trap). In fast mode they are disabled.
_debugPrecondition() and _debugPreconditionFailure()
These functions are meant to be used in library code to check preconditions that
are not neccesarily comprehensive for safety (UnsafePointer can be null or an
invalid pointer but we can't check both). They are enabled only in debug mode.
_sanityCheck() and _fatalError()
These are meant to be used for internal consistency checks. They are only
enabled when the library is build with -DSWIFT_STDLIB_INTERNAL_CHECKS=ON.
I modified the code in the standard library to the best of my judgement.
rdar://16477198
Swift SVN r18212
This re-applies r13380, reverted in r13406. I don't think this actually
caused any harm (r13400 was the primary culprit), but if it did I'd
like to actually see the buildbots or someone else's machine fail on it.
Swift SVN r13456
This substitutes swift_driver in as the new "swift". Tests that currently
test "%swift" will invoke "swift -frontend", much like "clang -cc1".
Most command-line interaction will look the same, except that Swift can
now emit linked libraries (using -emit-library) and executables (using
-emit-executable, or by not passing a mode option at all).
If you are working with @transparent functions, note that they will not be
properly inlined across file boundaries unless you use
-force-single-frontend-invocation, which emulates the old swift binary.
There are Radars for this already: <rdar://problem/15366167&15693042>
The name 'swift_driver' is now a symlink for 'swift'. This will be removed
next week.
The old 'swift' is still available as 'swift_old', though it is not being
tested at all. This will be removed in two weeks.
Clean CMake builds will get this immediately.
Incremental CMake builds will not get the new driver unless you explicitly
enable the SWIFT_NEW_DRIVER option (-DSWIFT_NEW_DRIVER=ON on the command line).
This option will go away in a week.
Makefile builds will get this immediately because I didn't want to work out
how to maintain both modes.
Much credit to Connor for bringing up the entire driver and for doing much
of the work in ensuring that all the tests continue to pass.
Swift SVN r13380
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
The hack to get the LLVM build system to do what we want is to define a
custom build rule for "XYZ.o" and then add "XYZ" as a dummy source file
to the SOURCES variable, which the LLVM Makefile system uses. To make it
clear that something unusual is going on here, I've changed all existing
instances of this to use "XYZ.o" in SOURCES, rather than having that name
be derived from "XYZ.swift" or whatever.
The actual Swift source files go in SWIFT_SOURCES for the time being
(and possibly forever, since Swift sources will always be built together).
Swift SVN r11058
...rather than as a separate step. This avoids duplicating Parse and Sema
work for these. (This is the new and correct version of r7377.)
Also, remove leftover code for building "swift.swift" and friends in lieu
of proper modules. We're not going back to those days. :-)
Swift SVN r7420
