Skip type-checking multi-statement branches if the
completion is in a single-expression branch, and
skip type-checking the expression as a whole if
the completion is in a multi-statement branch.
In a downstream project we are using the Swift code as a library and
compiling with C++20. This mostly works except for two backward
incompatibilities introduced by C++20:
* [P1008] disallows aggregate initialization when defaulted or deleted
constructors are specified. This lead to a compilation error for
aggregate initialization of `swift::Compilation::Result`. The backward
and forward compatible fix for that is to provide a constructor
turning aggregate initializations into a normal constructor call.
* [P1185] introduces more candidates for overload resolution of
comparison operator calls. As explained in [P1630], this leads in some
cases to ambiguity compilation errors in C++20, which is exactly the
case with `swift::ValueOwnershipKind`. The fix in this case is to
remove some redundant operator calls conditionally on the
`__cpp_impl_three_way_comparison` feature test macro, which [includes
the papers mentioned above][feature_test].
[P1008]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1008r1.pdf
[P1185]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1185r2.html
[P1630]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1630r1.html
[feature_test]: https://en.cppreference.com/w/cpp/feature_test
It is necessary for opaque values where for casts that will newly start
out as checked_cast_brs and be lowered to checked_cast_addr_brs, since
the latter has the source formal type, IRGen relies on being able to
access it, and there's no way in general to obtain the source formal
type from the source lowered type.
Eliminated HasConcretePack and added HasPack and HasPackArchetype.
Renamed the old `hasPack` to `hasAnyPack`; as before, it means that the
type has a parameter pack, a pack, or a pack archetype.
The old behavior was only correct when building substituted types,
ie, if createTupleType() was never called with a pack expansion type.
This was the case in the runtime's MetadataLookup which applies
substitutions to an interface type to ultimately construct metadata
for a fully-concrete type, but not in the ASTDemangler, where we
actually build interface types.
Since TypeDecoder doesn't have any way to query the kind of type
it just built, let's just instead make this decision inside the
implementation of the type builder concept.
Fixes https://github.com/apple/swift/issues/67322.
The compiler derived implementations of `Codable` conformances for enums did
not take enum element unavailability into account. This could result in
unavailable values being instantiated at runtime, leading to a general
violation of the invariant that unavailable code is unreachable at runtime.
This problem is possible because synthesized code is not type checked; had the
conformances been hand-written, they would have been rejected for referencing
unavailable declarations inside of available declarations.
This change specifically alters derivation for the following declarations:
- `Decodable.init(from:)`
- `Encodable.encode(to:)`
- `CodingKey.init(stringValue:)`
Resolves rdar://110098469
The reason why we are doing this is that this combination of read/set forces the
compiler to emit a copy if we want to emit a modify operation.
The reason why we are forced to emit such a copy is that:
1. _read provides a guaranteed value in memory
2. performing a modify requires an owned value in memory.
This together implies that the only way we can do this is to copy from the _read
into temporary memory. But we have a noncopyable type so we can't do this.
rdar://112915525
This is an inheritor of the existing `UnsafeCxxInputIterator` protocol, with the only difference being the ability to mutate `var pointee` via a non-const `operator*()`.
This is needed to support mutable subscripts for `std::map` via `CxxDictionary`.
rdar://105399019
Move the contextual type locator onto
ContextualTypeInfo, and consolidate the separate
fields in SyntacticElementTarget into storing a
ContextualTypeInfo. This then lets us plumb down
the locator for the branch contextual type of an
if/switch expression from the initial constraint
generation, rather than introducing it later. This
should be NFC.