Checking for the presence of a feature flag in order to allow syntax tends to
result in condfails when applied to `.swiftinterfaces`, since older compilers
that have this restriction may be used to compile newer interfaces where the
restriction has been lifted. Remove this restriction for non-escapable types
when typechecking an interface.
Resolves rdar://128577611
This implements support for autoclosures, closures and local functions
nested within a pack iteration for loop.
The combination of explicit closure expressions and pack expansion
expressions still needs some work.
Fixes#66917.
Fixes#69947.
Fixes rdar://113505724.
Fixes rdar://122293832.
Fixes rdar://124329076.
This adds a `getSpareBits` method to all the TypeInfo classes
that returns a suitable bitmask indicating the spare bits available
in values of this type. This gives us a way to recursively explore
the type tree and build up a full spare bit mask for an arbitrary type.
Happily, it appears we actually do have enough information to do this
calculation entirely from first principles, without requiring additional
reflection information. So once this is stable, we should remove my
earlier incomplete effort to publish spare bit mask info in the reflection
data, as that adds unnecessary metadata to every binary.
This doubtless still has plenty of holes, but seems sufficient
to handle a few basic enum types, including the stdlib DecodingError
which was used as an example to work out some key issues.
Now that SwiftCompilerSources are always enabled, `swift_in_compiler` is not needed anymore.
Set this feature unconditionally for tests which still include `REQUIRES: swift_in_compiler`.
There is a debug-build-only verification that is done for
alloc_pack_metadata instructions that checks that there exist paired
dealloc_pack_metadata instructions which will be keyed off of to clean
up the on-stack variadic metadata packs corresponding to (the
instruction after) the alloc_pack_metadata.
StackNesting omits the deallocation instruction (as does
PackMetadataMarkerInserter) if it would be created in a dead end block.
If all blocks in the dominance frontier of the alloc_pack_metadata
instruction are dead-end blocks, then the verification will incorrectly
fail. It should not fail because it is not necessary to clean up the
on-stack pack metadata (or any other stack allocations) in such a case.
If all such blocks are dead-end blocks, however, the
alloc_pack_metadata's block itself is a dead-end block as well. So
during the verification, check whether the alloc_pack_metadata occurs in
a dead-end block and do not fail verification if it does.
rdar://125265980
An empty struct without a deinit gets a single bit which is used to
track the struct's liveness. Previously, an empty struct with a deinit
also only got a single bit. Consequently, when discarding the struct
(i.e. dropping the deinit), there was no bit left to represent the
struct. This resulted in a failure to track liveness for the value.
rdar://126863003
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.
