Currently we set `FunctionRefKind::Compound` for
enum element patterns with tuple sub-patterns to
ensure the member has argument labels stripped. As
such, we need to account for the correct application
level in `getNumApplications`. We ought to be
setting the correct FunctionRefKind and properly
handling the label matching in the solver though.
We also ought to consider changing FunctionRefKind
such that "is compound" is a separate bit from the
application level.
rdar://139234188
If the base type of the specialization is invalid,
the AST node is going to be replaced with `ErrorExpr`.
We need to handle that gracefully when attempting
to apply specialization in such situations.
Resolves: https://github.com/swiftlang/swift/issues/77644
Situations like:
```
let _: Double = <<CGFloat>>
<var/property of type Double> = <<CGFloat>>
```
Used to be supported due to an incorrect fix added in
diagnostic mode. Lower impact here means that right-hand
side of the assignment is allowed to maintain CGFloat
until the very end which minimizes the number of conversions
used and keeps literals as Double when possible.
Resolves: rdar://139675914
Allow witnesses to introduce `any Sendable` types into their interface
before requirements (predicated on presence of `@preconcurrency` and
Swift 5 language mode) as a pathway for concurrency adoption.
Resolves: rdar://134503878
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
C++ foreign reference types have custom reference counting mechanisms, so they cannot conform to `AnyObject`.
Currently Swift's type system treats C++ FRTs as `AnyObject`s on non-Darwin platforms, which is incorrect. This change makes sure the behavior is consistent with Darwin platform, i.e. a cast of C++ FRT to `AnyObject` is rejected by the typechecker.
rdar://136664617
`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
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.
Check whether there are any opened generic parameters associated
with a declaration and if not, produce a fix which would be later
diagnosed as either a warning (in Swift 5 mode) or an error (if it
was a concrete type or the compiler is in Swift 6 language mode).
Resolves: rdar://135610320
`Any` used to be the type used to indicate placeholders before
and that's reflected in the score of the `DefineMemberBasedOnUse`,
this is no longer the same and the impact increase should be dropped.
If location (member) isn't mutable in the current context
or there are other problems at this location, increase impact
of the fix since it compounds the problem.
- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
Previously, the constraint solver would first attempt member lookup that
excluded members from transitively imported modules. If there were no viable
candidates, it would perform a second lookup that included the previously
excluded members, treating any candidates as unviable. This meant that if the
member reference did resolve to one of the unviable candidates the resulting
AST would be broken, which could cause unwanted knock-on diagnostics.
Now, members from transitively imported modules are always returned in the set
of viable candidates. However, scoring will always prioritize candidates from
directly imported modules over members from transitive imports. This solves the
ambiguities that `MemberImportVisibility` is designed to prevent. If the only
viable candidates are from transitively imported modules, though, then the
reference will be resolved successfully and diagnosed later in
`MiscDiagnostics.cpp`. The resulting AST will not contain any errors, which
ensures that necessary access levels can be computed correctly for the imports
suggested by `MemberImportVisibility` fix-its.
Resolves rdar://126637855.
