I think the original idea was to elide `Array<$T>` if there is
a binding a resolved generic arguments i.e. `Array<Float>`, but
the check doesn't account for the fact that bindings could be
of different kinds and there are some implicit conversions that
could be missed if we remove the bindings.
For example, given the following constraints:
`Array<$T0> conv $T1`
`$T1 conv Array<(String, Int)>`
`$T0` can be a supertype of `Array<$T0>` and subtype of `Array<(String, Int)>`.
The solver should accept both types as viable bindings because the
`$T0` could be bound to `(key: String, value: Int)` and that would
match `Array<(String, Int)>` conversion.
Allow inferring type of `inout` from a pointer type
(or optional thereof) but delay the binding set because
it might not be complete and object type of `inout` could
also be an Array or C-style pointer type.
If left-hand side of any conversion constraint is `inout` type
and right is a pointer (or optional thereof), delay simplification
until `inout` is at least partially structurally resolved (cannot
be a type variable or dependent member) because eager simplification
won't record all of the possible conversions.
Check whether there are any opened generic parameters associated
with a declaration and if not, produce a fix which would be later
diagnosed as either a warning (in Swift 5 mode) or an error (if it
was a concrete type or the compiler is in Swift 6 language mode).
Resolves: rdar://135610320
`Any` used to be the type used to indicate placeholders before
and that's reflected in the score of the `DefineMemberBasedOnUse`,
this is no longer the same and the impact increase should be dropped.
- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
This is related to 22e0f4a3d6.
Binding inference doesn't mark type variables that appear in
dependent member chains as "adjacent" which means that type
variables that represent generic arguments cannot be attempted
sooner due to incomplete information provided by the inference.
To fix this we'd need to remove `findInferrableTypeVars` and
replace its uses with `Type::getTypeVariables(...)`. This is
a risky change that would require some evaluation because it
could end breaking existing code but it would make sure that
for cases like `Row<$T0> conv $T1.ArrayLiteralElement` `$T0`
always gets associated with `$T1`.
Previously this would result in a fallback diagnostic because
type mismatches associated with `ExistentialConstraintType`
locations weren't handled at all.
10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
Make it clear the issue is the transfer of
control flow out of the `if`/`switch` expression.
Technically things like `break` and `continue` are
allowed, as long as they are not jumping out of
the expression.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
Previously, missing return diagnostics for unreachable subscripts
differed from the treatment unreachable functions received, leading to
inconsistent diagnostic behavior. This change removes the responsibility
for handling the relevant diagnostics from the AST code, in favor of the
diagnostics implemented via the SIL optimizer. Additionally, where the
AST-generation code would previously have diagnosed a missing return for
an implicit empty getter, it will now admit as valid, deferring the
missing return diagnostics to the later SIL passes.
Use `preCheckTarget` to pre-check the body,
allowing us to replace `PreCheckResultBuilderRequest`
with a request that only checks the brace for
ReturnStmts.
Always add constraints, find fixes during simplify.
New separate fix for allow generic function specialization.
Improve parse heuristic for isGenericTypeDisambiguatingToken.
Degrade concrete type specialization fix to warning for macros.
Doing it in the post-walk meant we ended up
walking the children twice, which lead to duplicate
diagnostics and incorrect inference of the
level of application for function references. Move
it to the pre-walk, ensuring that we resolve any
operator references before folding.
Always add constraints, find fixes during simplify.
New separate fix for allow generic function specialization.
Improve parse heuristic for isGenericTypeDisambiguatingToken.
Previously we could end up with a
ContextualMismatch fix and a MissingConformance fix
for different elements of the `matchTypes` disjunction,
leading to an ambiguity. Instead, avoid recording
the ContextualMismatch if we're matching an
existential, and tweak the MissingConformance
failure to have a custom diagnostic for
EnumElementPattern matching.
Make sure `CouldNotInferPlaceholderType` can
produce a diagnostic for a `PlaceholderType`
locator element, and avoid emitting an extra
diagnostic for a placeholder type in an invalid
position.
If closure appears inside of a pack expansion, the elements
that reference pack elements have to bring expansion's shape
type in scope to make sure that the shapes match.
Type variable reference collector needs to be augmented to collect
type variables associated with pack expansions that a closure references
elements of, otherwise it would get disconnected from the context.
Stored `let` properties of a struct, class, or actor permit
'inout' modification within the constructor body after they have been
initialized. Tentatively remove this rule, only allowing such `let`
properties to be initialized (assigned to) and not treated as `inout`.
Fixes rdar://127258363.
