This was causing cases of very long input pathnames to be mangled into
stats filenames greater than 255 characters long, which in turn meant
stats files were not being written in some cases.
This implementation required a compromise between parser
performance and AST structuring. On the one hand, Parse
must be fast in order to keep things in the IDE zippy, on
the other we must hit the disk to properly resolve 'canImport'
conditions and inject members of the active clause into the AST.
Additionally, a Parse-only pass may not provide platform-specific
information to the compiler invocation and so may mistakenly
activate or de-activate branches in the if-configuration decl.
The compromise is to perform condition evaluation only when
continuing on to semantic analysis. This keeps the parser quick
and avoids the unpacking that parse does for active conditions
while still retaining the ability to see through to an active
condition when we know we're moving on to semantic analysis anyways.
The user experience with extended grapheme literals is currently:
1. Strict: we hard error on "invalid" grapheme literals.
2. Complete: we validate all literals to either be
known-single-grapheme or not.
3. Incorrect: we have Unicode 8 semantics implemented but applications
will have some other version of Unicode as dictated by the OS they are
running on.
In Swift 4.0, this incorrectness mostly crops up in obscure corner
case areas, where we are overly restrictive in some ways and overly
relaxed in others. But, there is one particularly embarrassing area
where it does come up: we reject emoji introduced after Unicode 8 as
grapheme literals, counter to common user expectations.
In a future (sub-)version of Swift we should completely re-evaluate
this user story, but doing so in time for Swift 4.0 is untenable. This
patch attempts to tweak the way in which we are incorrect in the most
minimally invasive way possible to preserve the same user experience
while permitting many post-Unicode-8 emoji as valid grapheme literals.
This change overrides processing of ZWJ and emoji modifiers to not
declare a grapheme break after/before, respectively.
Our libcache implementation of swift::sys::Cache was broken for
ref-counted values (which are used by e.g. the SourceKit ASTManager).
It would always `retain(value)` in `set(key, value)`, but under the hood
libcache shares values, so we would only get one `release(value)` if the
same value was used across multiple keys, or if the same value *and* key
were set multiple times.
This was causing us to never release ASTs cached by SourceKit even when
the underlying libcache purged itself under memory pressure.
rdar://problem/21619189
Cygwin is considered a distinct target with a distinct ABI, environment
conditions, and data types. Though the goal of the project is
native Windows integration with UNIX-likes, that is not compatible with
the idea that the platform can be ignored as Win-like enough to have the
existing os(Windows) condition apply.
