We still had unavailable versions of these for floating-point types
only. We shouldn't need to keep these around, and can instead just
emit a helpful diagnostic for anyone that attempts to use them.
Unfortunately I don't see any way for the diagnostic to produce an
actual fix-it, so it just suggests '+= 1' or '-= 1' without actually
producing a fix.
* [Diagnostics] SR-7445 Improve diagnostics for assignment failures
* modified messages for assignments to function calls,
modified messages for assignments to methods.
removed comment for resolved radar.
* removed extra line and braces
* added tests for assignment_lhs_is_apply_expression
eliminated redundant literal check which is always invoked before call
reverted 'cannot assign to value' for literal assignments in subexpressions
* Complemented assigning to literal tests & reverted to 'cannot asign to value' for methods (was 'cannot assign to member')
* removed extra tabs
* eliminated one more accidental spacing
* Update CSDiag.cpp
* added highlighting, fixed & rechecked tests
* added highlighting for complex expressions involving assigning to literals
Resolves: [SR-7445](https://bugs.swift.org/browse/SR-7445)
We were not enforcing that operators were static if
the operator was defined in a final class, or if it
was defined in a non-final class but the operator was
itself final.
Fixes <rdar://problem/31469036>.
* One-sided ranges and RangeExpression
* Remove redundant ClosedRange methods from String
* Fix up brittle tests
* Account for Substring update
* XFAIL range diagnostics on Linux
wasn't being detected while parsing operator decls, and so declarations of
invalid operators would be accepted without error and then later couldn't
be used.
Now errors correctly and new tests added.
Member operators should be placed within a nominal type (or extension
thereof) that they operate on. Aside from being good style, enforcing
this in the type checker can help with dependency tracking. Addresses
rdar://problem/27536066.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
Allow 'static' (or, in classes, final 'class') operators to be
declared within types and extensions thereof. Within protocols,
require operators to be marked 'static'. Use a warning with a Fix-It
to stage this in, so we don't break the world's code.
Protocol conformance checking already seems to work, so add some tests
for that. Update a pile of tests and the standard library to include
the required 'static' keywords.
There is an amusing name-mangling change here. Global operators were
getting marked as 'static' (for silly reasons), so their mangled names
had the 'Z' modifier for static methods, even though this doesn't make
sense. Now, operators within types and extensions need to be 'static'
as written.
