Commit Graph

11 Commits

Author SHA1 Message Date
Dmitri Hrybenko
c109ec9125 stdlib: protocol extensions: de-underscore count()
Swift SVN r28246
2015-05-07 00:30:38 +00:00
Graham Batty
83b4384fac Update test flags for linux failures and support.
Also removed the sdk 'feature' in favour of the more specific
objc_interop.

Swift SVN r24856
2015-01-30 21:31:48 +00:00
Chris Willmore
68dd563fbf <rdar://problem/18311362> TLF: Eliminate implicit bridging conversions
Require 'as' when converting from Objective-C type to native type (but
continue to allow implicit conversion from native to Objective-C). This
conversion constraint is called ExplicitConversion; all implicit
conversions are covered by the existing Conversion constraint. Update
standard library and tests to match.

Swift SVN r24496
2015-01-18 00:07:45 +00:00
Graham Batty
83f27a8af7 Revert "Mark tests that don't pass on linux as XFAIL."
This reverts commit 2711ca86de7bf6a7885ccea24219a48a590b1e95.

Swift SVN r23577
2014-11-24 17:42:13 +00:00
Graham Batty
198402dcfe Mark tests that don't pass on linux as XFAIL.
Swift SVN r23573
2014-11-24 17:40:37 +00:00
Dave Abrahams
156020de19 [stdlib] Rename 'countElements' => 'count'
The name was not only long and unwieldy, but inconsistent with our
conscious decision to avoid the use of "elements" in APIs as mostly
redundant.

Swift SVN r22408
2014-09-30 22:00:26 +00:00
Doug Gregor
4ff01af85a Remove most of the 'NS' types from the dictionary pattern matching example.
This now makes use of bridging and IUO unwrapping in "switch".

Swift SVN r21020
2014-08-04 17:21:44 +00:00
Dave Abrahams
6d1095f44e Protocol names end in "Type," "ible," or "able"
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
2014-07-12 17:29:57 +00:00
Doug Gregor
67ca1c9ea1 Implement the new casting syntaxes "as" and "as?".
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
2014-05-22 06:15:29 +00:00
Joe Groff
f5500f2c57 Typos
Swift SVN r18227
2014-05-16 23:21:59 +00:00
Joe Groff
e49ca88a55 Check that some pattern-matching-heavy demo code actually runs.
Swift SVN r18223
2014-05-16 22:55:42 +00:00