Using inconsistent attributes between stdlib and tests causes
compilation errors. There are still several misuses of @_silgen_name in
tests, but leaving them as is for now to incrementally fix them.
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.
We don't expect to see type parameters that are not generic parameters
here, but dependent member types that wrap an ErrorType are fine, they
show up when a conformance had an invalid type witness.
Fixes the remaining example from https://github.com/apple/swift/issues/59384.
* Revert "Revert count(where:)"
This reverts commit 779ea19a6a.
Now that SE-0220 has been re-accepted, this adds the `count(where:)`
Sequence method to the standard library.
Now that the compilation model of noncopyable types is enabled everywhere,
and one can enable the feature for specific modules, we no longer need a
separate build-script/CMake option to enable it globally. Remove it all.
This test is failing to verify the generic signature for this bogus
program, because the generic signature isn't minimal. We should
gracefully handle this situation and still have a minimal signature,
despite rejecting this program.
When a no-payload enum is stored inside a multi-payload enum,
the outer enum may be using some of the extra high-order bits.
So when we examine the inner enum, we should just strip those bits.
We don't currently support building resilient relative protocol witness tables.
One might want to build with relative witness tables but not need
resilient protocols. Allow for that scenario.
Add a test configuration to test library-evolution + fragile resilient
protocols + relative protocol witness tables.
With this build-script has a flag --enable-experimental-nonescpable-types=1
to enable this feature in stdlib.
Also we can now add // REQUIRES: nonescapable_types to tests which run only when
the compiler is built with this feature turned on.
and implement it for @isolated(any) function types.
The existing testing was pretty broken: we were diagnosing all sorts
of things that don't require type metadata (like using a tuple with
an extended existential in a value position in an API signature)
and not diagnosing several things that do (like covariant function
conversions that erase types). There's therefore some risk to this
patch, but I'm not too worried because needing metadata like this is
pretty uncommon, and it's likely that programs won't build correctly
anyway --- it'll just get caught by the linker instead of the compiler.
- Pass down the TypeResolution instance so we can get the generic
signature. This ensures we always use the correct signature in
SIL mode.
- Don't diagnose if the type contains error types.
