<rdar://20494686>
String itsef should only expose Unicode-correct algorithms, like proper
substring/prefix/suffix search, enumerating words/lines/paragraphs, case
folding etc. Promoting sequence-centric algorithms to methods on String
is not acceptable since it invites users to write wrong code. Thus,
String has to lose its SequenceType conformance.
Nevertheless, we recognize that sometimes it is useful to manipulate the
String contents on lower levels (UTF-8, UTF-16, Unicode scalars,
extended grapheme clusters), for example, when implementing high-level
Unicode operations, so we can't remove low-level operations
altogether. For this reason, String provides nested "views" for the
first three low-level representations, but grapheme clusters were in a
privileged position -- String itself is a collection of grapheme
clusters. We propose to add a characters view that will represent the
String as a collection of Character values.
Swift SVN r28065
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
This fixes <rdar://problem/20494437> SILGen crash handling default arguments
again, and includes a fix for MiscDiagnostics to look through the generated
TupleShuffleExprs in @noescape processing (which tripped up XCTest).
This fixes <rdar://problem/16860940> QoI: Strict keyword arguments loses type sugar in calls
where we'd lose some type sugar.
This fixes sanity in the ASTs: ScalarToTupleExpr now always has consistent
types between its argument and result, so we can turn on AST Verification of it.
Swift SVN r27827
On that testcase, we now generate:
t.swift:8:22: error: integer literal '123456' overflows when stored into 'UInt8'
case tooFarByFar = 123456
^
t.swift:7:8: error: integer literal '256' overflows when stored into 'UInt8'
case twoHundredFiftySix
^
instead of spitting out some warnings with no source loc (which Xcode eats).
This patch:
- Propagates source locations for literals when synthesizing code in various places,
so we get the right diagnostic at the right spot.
- Improves the constant folding SIL Pass to print the value overflowing, which is
necessary for cases with an implicit value (like 256 above), and is general goodness
for the QoI of the diagnostic anyway.
Swift SVN r27756
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
Change all uses of "do { ... } while <cond>" to use "repeat" instead.
Rename DoWhileStmt to RepeatWhileStmt. Add diagnostic suggesting change
of 'do' to 'repeat' if a condition is found afterwards.
<rdar://problem/20336424> rename do/while loops to repeat/while & introduce "repeat <count> {}" loops
Swift SVN r27650
Fixes rdar://problem/20583365, and incidentally gets test/Interpreter/layout_reabstraction.swift to work without ObjC interop as well.
Swift SVN r27557
-observeValueForKeyPath now takes nullable parameters in new SDKs.
Fortunately, the test changes should still work with older SDKs because
we can override a T with a T?.
Swift SVN r27532
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
This isn't the right solution; we should be folding open-existentials
into the LValue machinery rather than subverting it. However, the test
cases are useful for we do get the right solution in place.
Swift SVN r27103
To properly deal with mutating methods on protocol extensions accessed through an existential (such as a property or subscript setter), open the existential as an lvalue so that its value can be mutated.
As part of this, make sure we form any OpenExistentialExprs at the top level of the expression if we didn't manage to build them sooner. This is a fairly ad hoc approach that I am not happy with (these could probably be placed better with a post-pass), but the cost of opening too early is fairly minimal.
Swift SVN r27068
A "switch" can't be empty, so special-case the 'code' implementation for an empty ErrorType to just return zero. It doesn't really matter what the value is since the enum can't be instantiated.
Swift SVN r26992
To use members of protocol extensions on existential types, we
introduce an OpenExistentialExpr expression to open up the existential
type (into a local archetype) and perform the operations on that local
archetype.
Unlike with uses of initializers or dynamic-Self-producing
methods of protocols, which produce similar ASTs, we have the type
checker perform the "open" operation and then track it through
constraint application. This scheme is better (because it's more
direct), but it's still using a simplistic approach to deciding where
the actual OpenExistentialExpr goes that needs improvement.
Swift SVN r26964
This library becomes a permanent interface that we would need to support
in the long term, so we should get dylib names and APIs right.
rdar://20418214
Swift SVN r26957
