'AnyObject' cannot be instantiated, we shouldn't be providing any
initializers on 'AnyObject' type. 'AnyObject(<HERE>' and global
completions with initializers (i.e. `addinitstotoplevel`) showed all
initializers from objc classes.
Note that, 'lookupVisibleMemberDecls()' on 'AnyObject' (i.e.
'AnyObject.<HERE>') doesn't return initializers even before this change.
But 'QualifiedLookup' did.
rdar://93059166
In case of ambigous expression/global completions, we call `getValueCompletionsInDeclContext` multiple times for the amigous solutions to the constraint system. This can cause modules to be included multiple times in `RequestedCachedResults` and thus global results from these modules are reported multiple times. Make `RequestedCachedResults` a set so we don’t get duplicate results.
rdar://92048610
The three options are now:
* `explicit`: Enforce Sendable constraints where it has been explicitly adopted and perform actor-isolation checking wherever code has adopted concurrency. (This is the default)
* `targeted`: Enforce Sendable constraints and perform actor-isolation checking wherever code has adopted concurrency, including code that has explicitly adopted Sendable.
* `complete`: Enforce Sendable constraints and actor-isolation checking throughout the entire module.
`isConcurrencyChecked()` was being used as a proxy for
`-warn-concurrency` that didn't account for Swift 6. Replace
checks against it within the current module with checks against the
strict concurrency level, which subsumes the Swift 6 check and can
account for the difference between "limited" and "on".
`isConcurrencyChecked()` is used now used exclusively to mean "treat a
missing Sendable conformance as an explicitly-non-Sendable type".
For ObjC NS_OPTIONS/NSDictionary parameters with some specific names,
ClangImporter implicitly adds default values. However, that behavior is
sometimes not really desirable. For example, for:
-(void)addAttributes:(NSDictionary *)attrs;
'attrs' is defaulted, but calling 'addAttributes()' doesn't make any sense.
In code-completion, consider such paramters non-defaulted.
rdar://89051832
Previously we didn't give any type relations to cached imported symbols.
So there was a hack to add the type matching nominal type with type
relation manually, which caused duplicated candiates, one from the
cache, one added manually.
Now that we have type relations for cached symbols so we don't need this
hack anymore.
rdar://90136020
This ensures that opened archetypes always inherit any outer generic parameters from the context in which they reside. This matters because class bounds may bind generic parameters from these outer contexts, and without the outer context you can wind up with ill-formed generic environments like
<τ_0_0, where τ_0_0 : C<T>, τ_0_0 : P>
Where T is otherwise unbound because there is no entry for it among the generic parameters of the environment's associated generic signature.
Computing the type relation for every item in the code completion cache is way to expensive (~4x slowdown for global completion that imports `SwiftUI`). Instead, compute a type’s supertypes (protocol conformances and superclasses) once and write their USRs to the cache. To compute a type relation we can then check if the contextual type is in the completion item’s supertypes.
This reduces the overhead of computing the type relations (again global completion that imports `SwiftUI`) to ~6% – measured by instructions executed.
Technically, we might miss some conversions like
- retroactive conformances inside another module (because we can’t cache them if that other module isn’t imported)
- complex generic conversions (just too complicated to model using USRs)
Because of this, we never report an `unrelated` type relation for global items but always default to `unknown`.
But I believe this change covers the most common cases and is a good tradeoff between accuracy and performance.
rdar://83846531
Computing the type relation for every item in the code completion cache is way to expensive (~4x slowdown for global completion that imports `SwiftUI`). Instead, compute a type’s supertypes (protocol conformances and superclasses) once and write their USRs to the cache. To compute a type relation we can then check if the contextual type is in the completion item’s supertypes.
This reduces the overhead of computing the type relations (again global completion that imports `SwiftUI`) to ~6% – measured by instructions executed.
Technically, we might miss some conversions like
- retroactive conformances inside another module (because we can’t cache them if that other module isn’t imported)
- complex generic conversions (just too complicated to model using USRs)
Because of this, we never report an `unrelated` type relation for global items but always default to `unknown`.
But I believe this change covers the most common cases and is a good tradeoff between accuracy and performance.
rdar://83846531
