This is a case that the operator splitting code didn't handle because of
the bizarre lexer code for handling operators with periods in them. We had
accreted some weird special case logic for what is valid in an operator
(but which even had a special case hack for ..<). The policy is now very
simple: if an operator name starts with a dot, it is allowed to include other
dots in its name. If it doesn't, it doesn't. This allows us to get lexer
level operator splitting in cases like x=.Foo, allowing our existing operator
set that have dots in them without hacks, and provides a superior QoI
experience due to operator splitting.
This is technically a language change, but the TSPL operator grammar was
incorrect for it anyway. I will file an internal radar to get TSPL updated
with the actual behavior (now that it is defensible).
When a line begins with '.', it's almost always due to a method chain, not an attempt to start an expression with a contextual member lookup. This is a more principled grammar rule than the long tail of hacks we've been putting up to try to accommodate "builder pattern" usages. Fixes rdar://problem/20238557.
Swift SVN r29606
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
Extend the character set for identifiers according to WG14 N1518, which recommends an extended character set for identifier start and continuation characters in C. Mangle identifiers containing non-ASCII characters by borrowing the Punycode encoding used for international domain names.
No Unicode operators just yet.
Swift SVN r4968
