Commit Graph

11 Commits

Author SHA1 Message Date
Max Moiseev
f51e708a8f Merge remote-tracking branch 'origin/master' into swift-3-api-guidelines 2016-01-04 12:25:25 -08:00
ken0nek
3ac60b13f5 Add spaces before and after closure arrow in test 2015-12-23 04:38:46 +09:00
Maxim Moiseev
2c95bb6d51 BooleanType => Boolean 2015-12-10 14:56:32 -08:00
Chris Willmore
42dba24464 Don't allow '{' at start of if-condition
If '{' is encountered immediately after 'if', assume that the condition
is missing. Apply the same treatment to while, do-while, for-in, and
switch. This way we're not trying to re-parse, backtrack, repurpose
misparsed closure bodies, etc. in those cases. Users who want to write a
condition that starts with '{' can wrap it in parens.

Addressing feedback re <rdar://problem/18940198>.

Swift SVN r25747
2015-03-04 05:39:49 +00:00
Dmitri Hrybenko
3b04d1b013 tests: reorganize tests so that they actually use the target platform
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
2015-01-19 06:52:49 +00:00
Dave Abrahams
cbcf9aba21 s/LogicValueType/BooleanType/
We're moving toward using that protocol for straight-up Bool types

Swift SVN r19884
2014-07-12 18:58:18 +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
0476b98d98 Ban the use of "as?" to coerce one value to another; it only makes sense for checked casts.
Addresses <rdar://problem/17029506>.


Swift SVN r18730
2014-06-06 05:39:31 +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
Ted Kremenek
fad874708e Adjust test cases.
Swift SVN r17964
2014-05-12 22:01:52 +00:00
Joe Pamer
dc42cbac74 When attempting to convert an expression type to a built-in protocol, it is incorrect to assume that the expression will always conform to that protocol. (Or if it doesn't that the protocol is "broken".) In these cases, produce an error type.
Swift SVN r14342
2014-02-25 17:34:26 +00:00