This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
Previously we would only do source ordering for
ClosureExprs, but other conjunctions need to have
their source location taken into account too, in
order to make sure we don't try and type-check e.g
a TapExpr in a second closure before we type-check
the first closure.
Also while here, switch to `std::min_element`
instead of sorting, and treat invalid source
locations as incomparable.
rdar://113326835
This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
Also avoid emitting the diagnostic for an out of
place binding pattern if there's an existing fix
on a parent call expression, as that's the real
source of the failure.
rdar://113025351
Such tuples should be treated specially because once pack expansion
is sufficiently resolved they'd get exploded and the resulting type
is what member lookup should use as a base.
Resolves: rdar://110721928
If a closure doesn't have a contextual type inferred yet it should
be delayed in favor of already resolved closure conjunction because
"resolving" such a closure early could miss result builder attribute
attached to a parameter the closure is passed to.
Partially resolves https://github.com/apple/swift/issues/67363
If one of the choices is variadic generic, let's use `matchCallArguments`
to find argument/parameter mappings and form pack expansions for arguments
when necessary.
Resolves: rdar://112029630
This matches what we do in VarRefCollector, and is
needed because we currently delay the pre-checking
of patterns due to the fact that we don't resolve
them until CSGen. We ought to consider changing
this, but until then, adjust the logic here to
ensure we properly connect an ExprPattern that
references an outer var with any type variables
it may involve.
rdar://112264204
The restriction that default arguments be disallowed from accessing
`@usableFromInline` decls is overbearing for library developers who need to
write non-trivial code to compute a default value, since it forces them to
either write a verbose closure inline in the function signature or expose a
`public` helper function which unnecessarily expands API surface. A
`@usableFromInline` function a more reasonable way to encapsulate a verbose
default value computation.
This reverses the semantic changes included in https://github.com/apple/swift/pull/15666.
Resolves rdar://112093794.
`test/Constraints/interpolation_segments.swift` has been removed
because interpolations are now type-checked together with their
context, so the separate type-checking test no longer applies.
As described in the issue #62922, the compiler should not allow to discard @noDerivative attribute and keep @differentiable. The patch adds a diagnostic for this case.
Resolves#62922.
Although variadic type is declared without `repeat` each of
its generic arguments is supposed to be a PackType which is
modeled in the interface type as `Pack{repeat ...}`. When
reference to such a type is opened by the constraint solver
we need to drop the Pack{repeat ...} structure because the
type variable would represent a pack type so `S<each T>`
is opened as `S<$T0>` instead of `S<Pack{repeat $T0}>`.
Resolves: https://github.com/apple/swift/issues/66095
This change causes explicit types written in the
source language that substitute a noncopyable type
for a type variable in a generic type to state
that's what's wrong. For example:
```
// NEW: noncopyable type 'MO' cannot be used with generic type 'Dictionary<Key, Value>' yet
// OLD: noncopyable type 'MO' cannot be used with generics yet
let _: [MO : T]
```
Only preserve primary associated types during type erasure if the
generic context does not contain outer generic prameters.
i.e.
Given `func foo { ... any P <Int> ... }` getNonDependentUpperBounds()
should produce any P<Int>
However, given `func foo<T> { ... any P<T> ... }` getNonDependentUpperBounds()
should produce any P
Fixes rdar://110262754
For `CTP_Initialization`, there's no contextual
type to record if the pattern is not a
`TypedPattern`. As such, tweak
`RequirementFailure::getDeclRef` to handle this
case.
We probably ought to reconsider how we handle
contextual types here, using a ContextualType
locator when there is no contextual type recorded
seems a bit weird, though in most cases we want
to treat initializations the same regardless of
if a TypedPattern was used. For now I'm leaving
that as future work.
rdar://111009224
If we have an identifier followed by either `[` or
a generic argument list, avoid turning it into a
binding pattern, as that would be invalid. This
is similar to the existing rule we have where a
following `(` prevents a binding pattern from
being formed.
This allows patterns such as `let E<Int>.foo(x)` and
`let (y[0], x)` to compile, where `x` is treated
as a binding, but no other identifier is.
rdar://108738034
Binding of pack expansion types is delayed until solving but use
of `Defaultable` was preventing it from being considered early
because that constraint impacts binding set ranking, switching
to `FallbackType` constraint give us better semantics where pack
expansion type variables are going to be bound as soon as they
have a contextual type.
Resolves: rdar://110819621
