This workaround is no longer needed because `TypeAliasType` is now
modeled using generic arguments (as opposed to a substitution map).
Previously, computing the substitution map in `StructuralTypeRequest` to
construct the resulting `TypeAliasType` could cause a request cycle
around generic signature computation.
Instead of canonicalizing platform versions during parsing and storing two
versions, just canonicalize the parsed version on-demand when its requested.
Warnings about unsafe uses due to an @unsafe IteratorProtocol conformance
(for the implicit call to next()) could not be silenced. Follow the same
path we did for the Sequence conformance (and makeIterator() call) by
associating it with the `unsafe` on the sequence argument.
This isn't the only solution here, but it's a reasonable one.
The implicit reference to the initializer was tripping up the logic
for finding the appropriate place to insert "unsafe", and it was ending
up in the middle of the expression.
We can't unconditionally skip the conformance check if the type contains type
parameters; instead, we only want to skip it in the structural resolution
stage. In interface resolution stage, we proceed by mapping the type into
the generic environment first.
This is required because `ApplicableFunction` constraint can
inject member reference constraints that require a declaration
context.
For example, `_ = { Double(...) }` would now produce a disjunction
for `Double.init` where overload choice declaration contexts point
to the closure instead of the enclosing context.
This addresses a long-standing FIXME in `simplifyApplicableFnConstraint`
and helps with disjunction optimizer because its correctness depends on
correct identification of declaration contexts where applications happen.
When calling an explicitly-@safe function or subscript, or accessing an
explicitly-@safe property, the direct arguments to that operation can be
considered safe if they are references to local variables or are references
to types.
This brings the implementation in line with the recent adjustments to the
proposal within the review.
Implicit initializers are given a source location within the type they belong to. This works poorly for @objc @implementation classes, because the class they belong to is imported and so those SourceLocs are in a different source buffer from the extension they’re inside, breaking an invariant enforced by index-while-building features.
Fix these SourceLocs to come from the implementation context, so they’ll come from the extension for an objcImpl class and the type itself otherwise.
When doing completion in a result builder, we avoid
solving unrelated expressions by replacing them with
unbound placeholder variables. Avoid penalizing
assigning holes to these placeholders, since
otherwise we end up unnecessarily exploring the
entire solution space, and bailing due to too
complex.
rdar://144382123
When a macro that has both 'member' and 'extension' roles is on a type,
and both list conforming protocols, the order in which those roles were
evaluated in the compiler could change the set of protocols passed to
the macro expansion function (via `conformingTo:`). Specifically, if
the extension macro was expanded first, the member macro would see the
extension providing the conformance to one of its protocols, and not
pass down that protocol to the member macro's `conformingTo:`.
Ensure that we account for already-expanded extension macros that
define conformances.
Fixes rdar://137080876.
