The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.
Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.
Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
I think the original idea was to elide `Array<$T>` if there is
a binding a resolved generic arguments i.e. `Array<Float>`, but
the check doesn't account for the fact that bindings could be
of different kinds and there are some implicit conversions that
could be missed if we remove the bindings.
For example, given the following constraints:
`Array<$T0> conv $T1`
`$T1 conv Array<(String, Int)>`
`$T0` can be a supertype of `Array<$T0>` and subtype of `Array<(String, Int)>`.
The solver should accept both types as viable bindings because the
`$T0` could be bound to `(key: String, value: Int)` and that would
match `Array<(String, Int)>` conversion.
Previously we would only call this in the delayed
application logic, which is currently run for
multi-statement closures. I'm planning on
removing that code path, which uncovered this
issue.
`resolveOverload` introduces a conversion if there were any adjustments
to a member type on existential base. This conversion exists only to
check adjustments in the member type, so the fact that adjustments also
cause a function conversion is unrelated.
Resolves: rdar://135974645
The generality of the `AvailabilityContext` name made it seem like it
encapsulates more than it does. Really it just augments `VersionRange` with
additional set algebra operations that are useful for availability
computations. The `AvailabilityContext` name should be reserved for something
pulls together more than just a single version.
Before the update to support the new syntax, the decl checker treated private and fileprivate members of objcImpl extensions as non-@objc by default. But SE-0436 specified that private and fileprivate members should be implicitly @objc unless opted out, so when support for the final syntax was added, this behavior was changed retroactively.
Unfortunately, we’ve found that some early adopters depended on the old behavior. Restore some logic deleted by #73309 for early adopter syntax *only*, with a warning telling the developer to put `final` or `@nonobjc` on the declaration if they want to preserve the behavior after updating it.
Also tweaks the ObjCImplementationChecker to ensure this logic will actually be run in time for it to suppress the “upgrade to @objc @implementation” warning, and corrects a couple of regressions arising from that change.
Fixes rdar://135747897.
Downgrade a mismatch on global actor attributes to a warning until
Swift 6 to enable class authors to introduce concurrency annotations
to overridable members.
Resolves: rdar://131347583
'type' and 'missingType' are contextual types in the generic environment
of the witness thunk. We cannot simply map them into the environment of
the conformance, because if the conforming type is a class, the witness
thunk has an extra generic parameter at depth=0, index=0 and all other
generic parameters are shifted down by one depth.
Allow inferring type of `inout` from a pointer type
(or optional thereof) but delay the binding set because
it might not be complete and object type of `inout` could
also be an Array or C-style pointer type.
If left-hand side of any conversion constraint is `inout` type
and right is a pointer (or optional thereof), delay simplification
until `inout` is at least partially structurally resolved (cannot
be a type variable or dependent member) because eager simplification
won't record all of the possible conversions.
Marking an observer unavailable (or potentially unavailable) has no effect
since the compiler emits calls to them unconditionally.
Resolves rdar://80337141.
It should not be possible to mark an associated type declaration unavailable
since doing so does not have an effect on how a conformance interacts with its
associated types.
