All refutable patterns and function parameters marked with 'var'
is now an error.
- Using explicit 'let' keyword on function parameters causes a warning.
- Don't suggest making function parameters mutable
- Remove uses in the standard library
- Update tests
rdar://problem/23378003
Now we can handle simple cases like
1 + 1 == 2 <here>
and correctly suggest both + on the 2 and || on the boolean. When the
LHS doesn't type-check we fallback to using only the operand immediately
to the left.
Swift SVN r32489
...into separate prefix, postfix and infix operators. Also incidentally
make the whitespace around operators special so we can decide when to
skip over it. Tested in SourceKit.
Swift SVN r32468
This allows us to start code-completing infix operators in postfix
expressions. As a first step, this patch only handles completing
against the immediate LHS (so for example 1 == 1 <here> doesn't suggest
boolean operators yet).
The next step is to feed the leading sequence expression from the parser
in so we can consider how the operator being completed fits into the
whole sequence expression.
For rdar://problem/22460167
Swift SVN r32465
This allows us to start code-completing postfix operators (generally !,
++, and --), which lays some of the groundwork for completing the much
more interesting infix operators.
These only show up when in postfix position
x<here>
For rdar://problem/22460167
Swift SVN r32355
...replacing it with the new, after passing API review!
* The lazy free function has become a property.
* Before we could extend protocols, we lacked a means for value types to
share implementations, and each new lazy algorithm had to be added to
each of up to four types: LazySequence, LazyForwardCollection,
LazyBidirectionalCollection, and LazyRandomAccessCollection. These
generic adapters hid the usual algorithms by defining their own
versions that returned new lazy generic adapters. Now users can extend
just one of two protocols to do the same thing: LazySequenceType or
LazyCollectionType.
* To avoid making the code duplication worse than it already was, the
generic adapters mentioned above were used to add the lazy generic
algorithms around simpler adapters such as MapSequence that just
provided the basic requirements of SequenceType by applying a
transformation to some base sequence, resulting in deeply nested
generic types as shown here. Now, MapSequence is an instance of
LazySequenceType (and is renamed LazyMapSequence), and thus transmits
laziness to its algorithms automatically.
* Documentation comments have been rewritten.
* The .array property was retired
* various renamings
* A bunch of Gyb files were retired.
Swift SVN r30902
Replace the Lazy-based implementations with open-coded implementations based on the _UnsafePartiallyInitializedContiguousArrayBuffer builder from the previous commit, so that we have control over the early-exit flow when an error interrupts the operation.
Swift SVN r30794
This covers:
- Lifetime-extending wrappers, like withExtendedLifetime, withCString, and withUnsafe*Pointer
- 'map' and friends on Optional
- 'indexOf'
A few APIs I haven't gotten to yet in this first pass:
- Autoclosure APIs, like assert, &&, etc.
- the 'isOrderedBefore' predicate for sorting APIs. The sorting implementation does some microoptimizations with 'inout' closures that violate rethrows checking.
- Strict 'map', 'filter', and friends on CollectionType. These need some plumbing in Lazy to be able to thread a Result-forming transformation through.
This version of the patch updates some protocol customization implementations that I missed the first time around, and includes the tests I forgot to add in the previous iteration.
Swift SVN r30790
This covers:
- Lifetime-extending wrappers, like withExtendedLifetime, withCString, and withUnsafe*Pointer
- 'map' and friends on Optional
- 'indexOf'
A few APIs I haven't gotten to yet in this first pass:
- Autoclosure APIs, like assert, &&, etc.
- the 'isOrderedBefore' predicate for sorting APIs. The sorting implementation does some microoptimizations with 'inout' closures that violate rethrows checking.
- Strict 'map', 'filter', and friends on CollectionType. These need some plumbing in Lazy to be able to thread a Result-forming transformation through.
Swift SVN r30597
protocol P { typealias T; func foo() -> T }
func invalid(x: P) { x.#^COMPLETE^#
We were trying to access a null Type created because the associated type
doesn't make sense in the protocol type P (we can only use P as a
generic constraint, but it shouldn't crash code completion if we use it
incorrectly).
For rdar://problem/20305938
Swift SVN r28588
<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
We explicitly whitelist these "stdlib private" decls in interface
generation, because they may contain methods that users are required to
implement. But in code-completion, there's no good reason to show them.
We still show completions for the methods themselves if you complete on
a public protocol that inherits from the private protocol. So,
<complete> => doesn't show _CollectionType
let a: CollectionType = ...
a.<complete> => *does* show startIndex, which comes from _CollectionType
rdar://problem/20086106
Swift SVN r26355
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Fixes rdar://problem/17229052
Make it clear C_ARGV var is unsafe.
Made it impossible to set the argc/unsafeArgv outside of the stdlib.
Refactored tests to not use C_ARG{C,V}.
Made C_ARG{C,V} unavailable.
Swift SVN r23249
that important protocols are not hidden
The rule essentially remains the same -- underscored symbols are stdlib
implementation details and users should not be relying on them. (Even
protocols like _Collection, are conceptually implementation details -- they are
not a part of the original design and we would like to remove them as soon as
the bugs are fixed.)
But since protocols define requirements for user types, we need to display even
underscored protocols, except for _Builtin* protocols, which can never be
satisfied by a user type.
rdar://16986307
Swift SVN r20083
Introduce the new BooleanLiteralConvertible protocol for Boolean
literals. Take "true" and "false" as real keywords (which is most of the
reason for the testsuite churn). Make Bool BooleanLiteralConvertible
and the default Boolean literal type, and ObjCBool
BooleanLiteralConvertible. Fixes <rdar://problem/17405310> and the
recent regression that made ObjCBool not work with true/false.
Swift SVN r19728
