When performing qualified lookup with MemberImportVisibility enabled, always
filter out all overridden methods that come from modules that have not been
imported. This ensures that new overrides of a method in dependencies are not
source breaking for dependents with MemberImportVisibility enabled. This
generalizes the logic added in https://github.com/swiftlang/swift/pull/81089
that was previously limited to overrides coming from Obj-C categories.
Resolves rdar://170089840.
Introduce new syntax for parsing arbitrary integer literal expressions for generic value arguments:
```swift
InlineArray<(<Expr>), T>
[(<Expr>) of T]
```
Which, for now, will co-exist alongside the current syntax of simple integer literals.
Replace `IntegerTypeRepr` with `GenericArgumentExprTypeRepr`, a new `TypeRepr` node that wraps arbitrary expressions in generic argument positions (e.g., `InlineArray<(1 + 3), Int>`). The node tracks resolution state, distinguishing whether the expression resolved to a type or an integer value.
Key changes:
- Parse parenthesized generic arguments as expressions
- Recover and distinguish types from integer expressions in `resolveGenericArgumentExprTypeRepr`.
- When the `LiteralExpressions` feature is enabled, type-check and constant-fold expressions to integer values
- Extract `PreCheckTarget` into a public header to expose `simplifyTypeExpr` for use during type resolution
Resolves rdar://168005391
We don't consider an associated type of a @reparentable protocol
to be an overridden decl of any protocols inheriting from it.
If we did, then it'd affect how getReducedType and other bits of
comparison between associated types work, because they prefer
anchors, i.e., associated types not overriding anything else
(see `swift::compareAssociatedTypes`).
That worked fine until availability checking brought to light that
name lookup also relies getOverriddenDecls() to determine which
associated type decl one would be the one we refer to in a protocol.
So in this case it's not the reduced type, but rather the actual
`DeclRefTypeRepr` that name-lookup finds for `Element`, that actually
_does_ need to view that one coming from the @reparentable one as being
"overridden", or shadowed I guess, by any other protocols downstream of it.
rdar://170819864
I could be confusing to have more than one, because one could
declare different conditions in the `where` clauses of the
extensions, to witness associatedtype requirements using
different types.
Imported C++ declarations have some complicated special cases relating to module ownership that module selectors did not previously take into account. This meant that members of C++ classes and namespaces would sometimes only allow a module selector of `__ObjC` rather than the module they would normally be attributed to. Fix this oversight.
We were walking the extensions of protocols in
requirement lowering and in getInheritedProtocols
to also count the @reparented entries in all
extensions. I had already seen some request
evaluator cycles triggered by this with objc
protocols, and it seems unnessecary as it's
actually a benefit to force people to write the
inheritance on the protocol itself.
This change forces you to write ``@reparented` relationships
on an extension of a protocol, rather than on the protocol
itself.
The ProtocolConformance needs to be associated with some
GenericContext and IRGen expects it to be an ExtensionDecl.
That environment defines under what conditions the conformance
exists. We also need to define witnesses for the new parent's
requirements in an extension anyway, so it's a natural fit.
The previous workaround for this was kind of awful, as it'd
require searching all the protocol's extensions and "guess"
which extension they want to represent the conformance. While
we could try to synthesize an extension, there's two
challenges there:
1. Due to SuppressedAssociatedTypes, it's not so simple to
synthesize an unconstrained ExtensionDecl.
2. We currently rely on same-type requirements to pin the
associated types to particular witnesses of those requirements
in the extension. So it's not purely unconstrained! For example,
```
extension Seq: @reparented BorrowSeq where Iter == MyIter {}
```
The constraints that are disallowed (but not yet diagnosed)
are conditional conformance requirements, as the default
conformance for a reparenting cannot depend on those.
Thus, it's better that programmers to specify the extension.
When a DeclRefTypeRepr is bound to a known declaration, the exact DeclNameRef used to create it is erased. This means that we no longer know exactly which module selector was used in the source code, so repeating the lookup with the same instance might produce different results.
Avoid this problem by reusing the bound decl instead of trying to look up the same declaration again.
Fixes rdar://164647850.
Lookups like Builtin::Int64 were failing because BuiltinUnit rejected all unqualified lookups. Make it allow unqualified lookups with a module selector.
Expressed as `__swift_attr__("~Sendable")` this acts like `: ~Sendable`
on Swift type declarations and supersedes `@_nonSendable(_assumed)`.
Resolves: rdar://140928937
We don't properly support peer declarations in local contexts, as such
if we have both a property wrapper and macro with a given name on a
local var, let's prefer the property wrapper.
rdar://148782639
Introduce CustomAttrOwner that can store either a Decl for an
attached attribute, or a DeclContext for e.g a type or closure
attribute. Store this on CustomAttr such that we can query it from
the name lookup requests.
Tuple extensions are still an experimental feature, but we have a
number of crashers in the repo for them because we still use their
type-checker machinery even when disabled. Change the logic here such
that we reject them early in extension binding when the feature is
disabled. This will ensure we address the crashers before productizing.
- Turn `BindExtensionsForIDEInspectionRequest` into the main extension
binding request.
- Change `ExtendedNominalRequest` such that it's no longer what
extension binding calls into to do the name lookup, instead it calls
directly into `computeExtendedNominal`. `getExtendedNominal` can
then be the entrypoint for `ExtendedNominalRequest` and assumes that
extension binding has already run. This avoids needing to fake the
dependency relationship in the DeclChecker.
The migration to `MemberImportVisibility` can be performed mechanically by
adding missing import declarations, so offer automatic migration for the
feature.
Resolves rdar://151931597.
Unlike in Swift, Obj-C allows method overrides to be declared in extensions
(categories), even outside of the module that defines the type that is being
extended. When MemberImportVisibility is enabled, these overrides must be
filtered out to prevent them from hijacking name lookup and causing the
compiler to insist that the module that defines the extension be imported.
Resolves rdar://145329988.
The decl checker was effectively not being run on these because we weren’t typechecking the PBD and typechecking the VarDecl itself is basically a no-op.
Unlike in Swift, Obj-C allows method overrides to be declared in extensions
(categories), even outside of the module that defines the type that is being
extended. When MemberImportVisibility is enabled, these overrides must be
filtered out to prevent them from hijacking name lookup and causing the
compiler to insist that the module that defines the extension be imported.
Resolves rdar://145329988.
* [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.
This is very brittle in this first iteration. For now we require the
declaration representing the availability domain be deserialized before it can
be looked up by name since Clang does not have a lookup table for availabilty
domains in its module representation. As a result, it only works for bridging
headers that are not precompiled.
Part of rdar://138441266.
Instead of using the `isolated P` syntax, switch to specifying the
global actor type directly, e.g.,
class MyClass: @MainActor MyProto { ... }
No functionality change at this point
Konrad Malawski
Allan Shortlidge
Artem Chikin
Kavon Farvardin
Becca Royal-Gordon
Anthony Latsis
Slava Pestov
Pavel Yaskevich
Hamish Knight
Pavel Yaskevich
Alejandro Alonso
Doug Gregor