This includes changing the feature name so that compilers with the experimental feature don’t accidentally pick up content that only works in the final version.
Resolves rdar://150065196.
Importing C++ class templates in symbolic mode has proven to be problematic in interaction with other compiler features, and it isn't used widely. This change removes the feature.
rdar://150528798
Guard against condfails when older compilers get a swift interface
that uses `@extensible` attribute. The attribute itself doesn't
have any effect in swift interfaces yet since all of the public
enums are already resilient in that mode.
When a language feature is used inside an `@abi` attribute, we should behave as though it was used on its counterpart. This was already half-implemented—we ensured the counterpart would use the feature—but we didn’t make the ABI decl aware that the counterpart was its parent for feature detection purposes. As a result, we would print `#if` inside the `@abi` attribute, which isn’t valid.
Add a new language feature to avoid the stdlib’s swiftinterface becoming unintelligible to outdated compiler builds due to the generalization of Builtin.is_same_metatype.
rdar://149396721
For now the semantics provided by `@extensible` keyword on per-enum
basis. We might return this as an upcoming feature in the future with
a way to opt-out.
Building on top of PR #79288, this update synthesizes a static factory method using the default new operator, with a call to the default constructor expression for C++ foreign reference types, and imports them as Swift initializers.
rdar://147529406
This feature only exists as a mechanism to suppress the warning introduced in
https://github.com/swiftlang/swift/pull/75378. The RegexParser module, which is
effectively part of the standard library, declares a Swift runtime symbol and
as a result every build of the compiler and stdlib produces warnings which
there are no plans to address. Warnings that are not going to be addressed need
some way of being suppressed, and an experimental features seems like a
reasonable mechanism for this one.
* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.
Introduce the experimental feature InferIsolatedConformances to align
with the upcoming feature proposed in SE-0470. This is a slight
generalization of the main-actor-specific inference that was already
in place for the default-main-actor mode from SE-0466. Note that, as
specified in SE-0470, InferIsolatedConformances is implied by the
default-main-actor mode.
