The issue here was that we inferred the contextual type of the `Mixer` call to be the following, inferred from the result type of the partial call to the initializer of `Mixer`
```
(bound_generic_struct_type decl="swift_ide_test.(file).Mixer@/Users/alex/src/swift/test/IDE/complete_parameter_pack_as_call_argument.swift:3:8"
(pack_type num_elements=1
(pack_expansion_type
(pattern=unresolved_type)
(count=unresolved_type))))
```
Technically, the contextual type that we should have here should be `Any` (from `print`) but getting that information out of the constraint system turns out to be quite hard. https://github.com/apple/swift/pull/72568 makes some improvements in this area but in general the constraint system does not contain enough information to figure out the contextual type of an arbitrary expression.
The important thing right now is that the unresolved type in here trips the constraint system over when comparing types of code completion results with the contextual type. To prevent the crash for now, reset the expected call type if the computed type contains an unresolved type.
rdar://124166587
Co-authored-by: Pavel Yaskevich <pyaskevich@apple.com>
To compute the expected type of a call pattern (which is the return type of the function if that call pattern is being used), we called `getTypeForCompletion` for the entire call, in the same way that we do for the code completion token. However, this pattern does not generally work. For the code completion token it worked because the code completion expression doesn’t have an inherent type and it inherits the type solely from its context. Calls, however, have an inherent return type and that type gets assigned as the `typeForCompletion`.
Implement targeted checks for the two most common cases where an expected type exists: If the call that we suggest call patterns for is itself an argument to another function or if it is used in a place that has a contextual type in the constraint system (eg. a variable binding or a `return` statement). This means that we no longer return `Convertible` for call patterns in some more complex scenarios. But given that this information was computed based on incorrect results and that in those cases all call patterns had a `Convertible` type relation, I think that’s acceptable. Fixing this would require recording more information in the constraints system, which is out-of-scope for now.
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
I had to change the APIs to always be always emit into client instead of back
deployable since silgen_name seems to interfere with @backDeployment. So I
switched the implementation so that it instead uses an always emit into client
thunk with the in source function name and a usableFromInline function that has
the silgen_name. This ensures that we still appropriately export the same symbol
as we did before, so it is ABI stable.
This was approved as part of se-0414.
rdar://122030520
Generated interfaces for Clang modules used to try printing normal
comments between decls extracted from the header text. That was because
doc-comment was not common in C/ObjC headers. But mainly because of
"import as member feature" Clang decls aren't printed in the order as
they appear in the header file, the logic determinig which comment
belongs to which decl was not working property. We've decided to remove
that feature and only print the proper doc-comments as it has been
getting common.
rdar://93731287
In rdar://123649082, a project failed to build because of the lazy import-as-member loading changes in #71320. That project was configured in a way that broke modularization and the correct solution is to fix it, but out of an abundance of caution, add a `-disable-named-lazy-import-as-member-loading` frontend flag in case a project needs to temporarily restore the old behavior.
As a bonus, this lets us write a test to verify that lazy import-as-member loading has positive performance impact.
ClangImporter’s SwiftLookupTables map Swift names to their corresponding Clang declarations. These tables are built into a module’s clang .pcm file and missing or inaccurate entries can cause name lookup to fail to find an imported declaration.
Swift has always included a helper function that would dump these tables, and swift-ide-test has a command-line switch that would invoke it, but these tools are clumsy to use in many debugging scenarios. Add a frontend flag that dumps the tables at the end of the frontend job, making it a lot easier to get at this information in the context of a specific compilation.
When completing in cases like `bar(arg: foo(|, option: 1)`, we don’t know if `option` belongs to the call to `foo` or `bar`. Be defensive and also suggest the signature.
Requirement lowering only expects that it won't see two requirements
of the same kind (except for conformance requirements). So only mark
those as conflicting.
This addresses a crash-on-invalid and improves diagnostics for
move-only generics, because a conflict won't drop the copyability
of a generic parameter and expose a move-only-naive user to
confusing error messages.
Fixes#61031.
Fixes#63997.
Fixes rdar://problem/111991454.
Unify the implementation between single-expression
and multi-statement closures. Because we're now
storing a contextual type for single expression
closure returns, update a code completion test to
bring its behavior inline with the multi-statement
case.
This can occur for e.g multi-statement closure
returns (and soon for singe-expression closures
too), so fall back to evaluating the expression
type if it's not fully resolved.
