`compiler(>=)` is the simplest/best way to write code that needs to only
be built on a particular toolchain version. For that to work, we cannot
have the `main` branch report itself as the same version as
`release/6.3`; accordingly, bump the compiler version number to 6.4.
(The Swift Standard Library already reports itself as 6.4. If the `main`
branch ends up shipping under some other Swift version, then we can
simply update this as needed, like we did with 5.11 → 6.0.)
---------
Co-authored-by: Mishal Shah <shahmishal@users.noreply.github.com>
This test has been XFAILed since 2016 despite merely missing an error
expectation. However, given that the obsoleted pre-Swift-3 metatype
syntax tested here has not had a tailored compatibility diagnostic since
at least Swift 3 (the compiler), I do not think it carries its weight.
Resolves rdar://16172507.
swift-synthesize-interface needs to match the safe interop wrappers
setting of the compiler invocation that built the Swift module, but
doesn't have -enable/disable-experimental-feature options. Instead of
introducing them for a single feature, which isn't even experimental,
this introduces the -disable-safe-interop-wrappers instead.
This enables the stable subset of safe interop wrappers by default. It
can be manually disabled using
`-disable-experimental-feature StabilizedSafeInteropWrappers`.
rdar://148994016
lifetimebound does not imply that the parameter does not escape. For
stabilising safe wrappers we don’t want to use that assumption, so we
need a new feature flag.
rdar://170090534
Make sure we don't ever try to record semantic tokens for a different
buffer. This works around an ASTWalker issue where it will walk macro
expanded bodies even in non-macro-expansion mode.
rdar://165420658
For semantic functionality the API decl is the more useful thing to
mangle, and redeclaration checking ensures we can't end up with
conflicts. This ensures we're able to perform a name lookup for the
decl based on its USR without having to maintain a separate lookup
table for ABI names.
Make sure we avoid adding these to the entity stack entirely, which
avoids hitting the assertion that a top-level entity isn't encountered
with a non-empty stack.
This adds a check in lit.local.cfg for whether the current C++ stdlib
contains the 'span' header. If so, the llvm-lit feature 'std_span' is
set. Also adds 'REQUIRES: std_span' to interop tests that include
'span'. This means we no longer have to choose between blanket disabling
`std::span` tests on all Linux distributions, or listing every Linux
distro with a libstdc++ version without `std::span` support as
unsupported.
I couldn't find any existing path to the MSVC stdlib in lit, and we
don't test versions of MSVC old enought to not support std::span
anyways, so 'std_span' is unconditionally enabled when targeting
windows-msvc.
rdar://161999160
rdar://161999174
rdar://162106580
rdar://162106619
rdar://162106643
rdar://162106653
rdar://162106722
rdar://162106747
This reverts most of 72050c5385, which led to decreased performance of jump-to-definition.
Instead of re-attempting to generate a module interface with C++ interop enabled, Swift should rely on the IDE to pass the correct `-cxx-interoperability-mode=` value to SourceKit.
rdar://149061322
In preparation for removing UnresolvedType in favor of ErrorType,
start printing ErrorType as `_` unless we've enabled debug printing.
`<<error type>>` should never be presented to the user, instead `_`
now just consistently means "unknown type".
