This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
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.
This removes conformance of DarwinBool and ObjCBool to the Boolean protocol,
and makes the &&/||/! operators be concrete w.r.t. Bool instead of abstract
on Boolean.
This fixes some outstanding bugs w.r.t diagnostics, but exposes some cases
where an existing diagnostic is not great. I'll fix that in a later patch
(tracked by rdar://27391581).
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
along with recent policy changes:
- For expression types that are not specifically handled, make sure to
produce a general "unused value" warning, catching a bunch of unused
values in the testsuite.
- For unused operator results, diagnose them as uses of the operator
instead of "calls".
- For calls, mutter the type of the result for greater specificity.
- For initializers, mutter the type of the initialized value.
- Look through OpenExistentialExpr's so we can handle protocol member
references propertly.
- Look through several other expressions so we handle @discardableResult
better.
as a failure to convert the individual operand, since the operator
is likely conceptually generic in some way and the choice of any
specific overload is probably arbitrary.
Since we now fall back to a better-informed diagnostics point, take
advantage of this to generate a specialized diagnostic when trying to
compare values of function type with ===.
Fixes rdar://25666129.
This reverts commit 073f427942,
i.e. it reapplies 35ba809fd0 with a
test fix to expect an extra note in one place.
as a failure to convert the individual operand, since the operator
is likely conceptually generic in some way and the choice of any
specific overload is probably arbitrary.
Since we now fall back to a better-informed diagnostics point, take
advantage of this to generate a specialized diagnostic when trying to
compare values of function type with ===.
Fixes rdar://25666129.
wraps up SE-0004 and SE-0029.
I consider the diagnostic changes in Constraints/lvalues.swift to be
indicative of a QoI regression, but I'll deal with that separately.
The AvailabilityWalker was creating a new AvailabilityWalker instance whenever it
recursed through an assignexpr or memberrefexpr, which produced a new ExprStack.
This caused the fixit mechanics for migrating ++/-- to think that the ++/-- was
at the top level, when it wasn't.
My previous commit here didn’t work correctly for nested tuples, both
because it didn’t recurse into them to propagate access kind correctly
and because an outer TupleIndex overload (when indexing into the nested
tuple) could still be expecting an lvalue type.
This fix is much better. ConstraintSystem::resolveOverload now
correctly always expects rvalue types from rvalue tuples. And during
applyMemberRefExpr, if the overload expects an rvalue but the tuple
contains lvalues, coerceToType() correctly does any recursive munging
of the tuple expr required.
In SR-628 in particular, the problem was an assert that an AccessKind
was being set on a non-lvalue, but there were lots of asserts here in
various scenarios, the most common other ones being an AccessKind not
being set assertion by the ASTVerifier or lvalue-ness not matching
between tuple expr and tuple element expr.
This checks for lvalues in the tuple when a tuple indexing expr is built,
and if there are any, inserts load exprs into the lvalue elements to make all rvalues.
