It seems not-great that the same candidate can get into the overload set for a DeclRefExpr
multiple times, but if it does, don't expose this to the user.
Swift SVN r20315
modifiers and with the func implementations of the operators. This resolves the rest of:
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
Swift SVN r19931
eliminating the @'s from them when used on func's. This is progress towards
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
This also consolidates rejection of custom operator definitions into one
place and makes it consistent, and adds postfix "?" to the list of rejected
operators.
This also changes the demangler to demangle weak/inout/postfix and related things
without the @.
Swift SVN r19929
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
JoeP helped tweak things to ensure that pointer conversions are still
considered, but we no longer need the disjunction on InOutExprs to accommodate
user-defined inout conversions.
This causes some regressions in error reporting:
<rdar://problem/17489983> inout type mismatches complain about '@lvalue inout T'
<rdar://problem/17489894> inout not rejected as operand to assignment operator
Swift SVN r19306
One difficulty in generating reasonable diagnostic data for type check failures has been the fact that many constraints had been synthesized without regard for where they were rooted in the program source. The result of this was that even though we would store failure information for specific constraints, we wouldn't emit it for lack of a source location. By making location data a non-optional component of constraints, we can begin diagnosing type check errors closer to their point of failure.
Swift SVN r18751
coercion. Overload resolution uses this argument deduction when
dealing with generic functions, to determine when we can invoke a
generic function. When a generic function is selected, we create a
SpecializeExpr wrapping the DeclRefExpr to the generic function.
This is sufficient to type-check calls to simple things like a call to
func identity<T>(x : T) -> T { return x }
with a value of known type. However, it's missing far too many pieces
to enumerate.
Swift SVN r2230
