LLVM r334399 (and related Clang changes) moved clang::VersionTuple to
llvm::VersionTuple. Update Swift to match.
Patch by Jason Molenda.
rdar://problem/41025046
These new types are not yet imported for Swift but they need to be
included in the switch cases to avoid -Wswitch warnings that get promoted
to errors when building with -Werror.
Clang r331244 added experimental support for a proposed char8_t type.
It is currently enabled only with a special flag so this change for
Swift only attempts to get the compiler to build, not to make use of
the new type.
...so that we don't have to keep coming back to update it every major
release. And also so we can actually put methods on it instead of
using free functions.
No intended behavior change (yet).
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
This is an opencl type that we did not use in the compiler anyways. Our only use
was to make sure that we had covered switches on clang builtin types (and
asserted if we ever hit that case in a switch).
Don't bail out early when there's no deprecated-as-unavailable mode;
we also use the loop to check for `availability(swift, unavailable)`.
No test because the only callers are for Objective-C declarations.
If the keyword 'static' also appears within the '[' and ']' of the
array type derivation, then for each call to the function, the
value of the corresponding actual argument shall provide access to
the first element of an array with at least as many elements as
specified by the size expression. (C11 6.7.6.3p7)
Limit this change to Swift 4 so as not to break existing code, though
use of 'static' in this way is rare to begin with and passing nil
would probably be an error anyway.
Small part of rdar://problem/25846421.
Swift side of this new flag. This allows Objective-C framework authors
to replace a pair of methods by properties without breaking source
compatibility. This is especially important for class properties,
which were only introduced last year.
Still to come: importing the accessors even when this flag isn't set,
in order to provide better QoI when migrating from a method interface
to a property interface.
Part of rdar://problem/28455962
Name Importer wraps references to the Swift context and other needed
encapsulation. The eventual goal is to allow name lookup tables to
live separately from the Impl, and do better Clang-instance-based
caching in the future, as well as general separation of concerns.
NFC
Pull omitNeedlessWordsInFunctionName off of the Impl, and into a
static function local to ImportName.cpp. Separate it out from the Impl
entirely. Though this adds a couple of extra ugly parameters, it's one
of the last bits of tie-in between importFullName and the Impl.
By refactoring out PlatformAvailability from the ClangImporter, we can
more easily refactor out isUnavailableInSwift from the impl, which
will free us up to do more flexible import naming.
Introduces new files ClangAdapter.h/cpp, which will serve as a
convenient place to put code reasoning about Clang details. Refactors
out most Clang-related is*, has*, and get* methods from the
ImporterImpl. In the future, an adapter class could help serve to
seperate the concerns of the importer from the details of how to
correctly use Clang APIs.
