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.
This helps disambiguate files that might otherwise be hard to sort through
if multiple runs output stats together in a single directory. The names
don't have to be perfect, just contain sufficient hints (and be parseable)
to differentiate module, arch, opt and output-type variation in jobs.
Deserializing a witness record in a conformance may fail if either of the requirement or witness changed name or type, most likely due to SDK modernization changes across Swift versions. When this happens, leave an opaque placeholder in the conformance to indicate that the witness exists but we don't get to see it. For expedience, right now this just witnesses the requirement to itself, so that code in the type checker or elsewhere that tries to ad-hoc devirtualize references to the requirement just gets the requirement back. Arguably, we shouldn't include the witness at all in imported conformances, since they should be an implementation detail, but that's a bigger, riskier change. This patch as is should be enough to address rdar://problem/31185053.
