Commit Graph

18 Commits

Author SHA1 Message Date
Pavel Yaskevich
58329e0c27 Revert "[Diagnostics][Qol] SR-11295 Emit diagnostics for same type coercion. " 2019-10-25 01:05:07 -07:00
Luciano Almeida
86ca3454d6 Fixing warning UnnecessaryCoercion tests 2019-10-21 23:11:21 -03:00
Pavel Yaskevich
72b61f55bf [Diagnostics] Tailored diagnostic for "condition" expression
Since all condition expressions supposed to be convertible
to `Bool`, let's use that type as contextual and produce a
tailored diagnostic.
2019-09-20 12:37:35 -07:00
David Farler
b7d17b25ba Rename -parse flag to -typecheck
A parse-only option is needed for parse performance tracking and the
current option also includes semantic analysis.
2016-11-28 10:50:55 -08:00
Michael Gottesman
a047bb7564 Revert "Fix the build."
This reverts commit dc24c2bd34.

Turns out Chris fixed the build but when I was looking at the bots, his fix had
not been tested yet, so I thought the tree was still red and was trying to
revert to green.
2016-07-17 16:29:18 -07:00
Michael Gottesman
dc24c2bd34 Fix the build.
This reverts commit b4cba58330.
This reverts commit a602927c75.
This reverts commit 55fbe5a763.
2016-07-17 16:17:15 -07:00
Chris Lattner
55fbe5a763 Remove Boolean as a special, privileged type used by Sema, and instead
use the concrete Bool type.  This eliminates a bunch of complexity and
makes diagnostics more concrete.
2016-07-17 15:14:24 -07:00
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