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.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
This expands the downgrade for Objective-C requirements to all requirements
until strict concurrency checking is enabled (either via a flag in Swift 5
language mode or by switching to Swift 6 language mode).
Resolves: rdar://134503878
We used to detect partial applications based on member locators
and parent expressions, but using function reference kind +
check to see if self is applied is such simpler and hits both
uses of `isPartialApplication`.
Increases the default score of the `treat r-value as l-value`
and decrease the impact if the immediate member is settable
because that means that the problem is somewhere in the "base".
Placeholders propagate but we still can allow contextual inference,
to facilitate that the solver should consider `l-value object` constraint
to be solved and allow placeholders on "object" type.
Some invalid specializations were previously allowed by the compiler
and we found some existing code that used that (albeit invalid) syntax,
so we need to stage that error as a warning until Swift 6 language mode
to avoid source compatibility break.
Resolves: rdar://134740240
Previously this would result in a fallback diagnostic because
type mismatches associated with `ExistentialConstraintType`
locations weren't handled at all.
