There was a bunch of logic to lazily populate replacement types
corresponding to reducible generic parameters. This didn't seem
to have a clear purpose so let's remove it.
Add a case for completing type attributes in
inheritance clause position, and limit the
completion of `@unchecked`, `@preconcurrency`, and
`@retroactive` to that case.
Attempting to favor a disjunction choice here
can lead to unhelpful results if there's e.g a code
completion token argument, since it acts as a
placeholder.
rdar://127844278
Complete ownership specifiers such as `consuming`,
`borrowing`, and `inout` in parameter type
position. While here, also complete `isolated`.
rdar://127261573
Defining it as a `DECL_KEYWORD` means code
completion will try and complete it in decl
position. It shouldn't really be considered a decl
keyword, so define it as `SWIFT_KEYWORD`.
If the extension does not match the protocol type
that we're doing the lookup for, check whether the
`Self` type conforms to the protocol; in that case
we have e.g an extension for an inherited protocol.
rdar://129024996
Previously we would skip any expression in a
result builder that didn't contain the completion
token, but that would cause issues if e.g the
result builder was needed to infer the type of a
variable that we're completing on. Instead, only
skip expressions in a result builder if the
completion token is in the same builder and the
expression itself doesn't contain the completion.
rdar://127154780
For unresolved member completion, we were preferring
the more general type, when we ought to be preferring
the more specific type. Additionally, for both
unresolved member and postfix completion we were
opening archetypes, which doesn't work as expected
since we don't compare requirements. Factor out
the logic that deals with merging base types for
lookup, and have it prefer either the subtype, or
the optional type in the case of optional promotion.
rdar://126168123
`Res.FirstTrailingClosureIndex` is an index into
the argument list, so comparing it against a
parameter index is wrong. Instead, compare it
against the argument index of the completion token,
which is what we want to be checking. This ensures
we don't try and offer argument completions for
non-function default arguments.
rdar://127760308
While one can disable building the embedded stdlib, the tests for that
feature were unconditionally added. If one wants to just build the
compiler without any stdlib (except target), a bunch of embedded tests
would have failed.
Inject the value of `SWIFT_SHOULD_BUILD_EMBEDDED_STDLIB` into the Lit
test system as a feature `embedded_stdlib` and add `REQUIRES:` to
a couple of tests outside the `embedded/` directory that seems to use
the experimental feature. Make the tests in `embedded/` unsupported in
the local Lit configuration file.
This warnings don't give much benefits for developers. Code completion
UI tends to show them unusable. But usually, developers can modify the
context to accept async calls, e.g. by wrapping it with `Task { }`
rdar://126737530
Previously code completion for 'catch' pattern bound values didn't work
correctly because code completion type checker fails to type check the
value decl in the pattern.
That was because the body of the 'do' statement is not type checked, so
the thrown error is not determined, then falled backed to the default
'Never', which doesn't matches any patterns.
To resolve this, always type check the body when typechecking 'catch'
patterns. Also, pretends 'do {}' throws 'any Error' even without
any throwing expressions in the body.
rdar://126699879
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
