Let's keep track of type mismatch between type deduced
for the body of the closure vs. what is requested
contextually, it makes it much easier to diagnose
problems like:
```swift
func foo(_: () -> Int) {}
foo { "hello" }
```
Because we can pin-point problematic area of the source
when the rest of the system is consistent.
Resolves: rdar://problem/40537960
when skipping to the end of the interpolated expression.
i.e. Skip the comment as a comment.
Previously, ')' or '"' in comment in interpolated expression used to
cause assertion failure or mis-compilation in no-assert build.
rdar://problem/20289969
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
`\.self` is the final chosen syntax. Implement support for this syntax, and remove the stopgap builtin and `WritableKeyPath._identity` property that were in place before.
We previously allowed these closures to default to (), but be inferred
as other types as well, which means that we will find some expressions
to be ambiguous because we end up finding multiple viable solutions
where there is really only one reasonable solution.
Fixes: rdar://problem/42337247
If generic parameter associated with missing conformance comes
from different context diagnose the problem as "referencing" a
specific declaration from affected type.
Instead of simply pointing out which type had conformance failures,
let's use affected declaration instead, which makes diagnostics much
richer e.g.
```
'List<[S], S.Id>' requires that 'S.Id' conform to 'Hashable'
```
versus
```
initializer 'init(_🆔)' requires that 'E' conform to 'Hashable' [with 'E' = 'S.Id']
```
Since latter message uses information about declaration, it can also
point to it in the source. That makes is much easier to understand when
problem is related to overloaded (function) declarations.
Since constraint solver has been improved to diagnose more problems
via "fixes", sometimes applying fixes might lead to producing solutions
which are completely ambiguous when compared to each other, and/or are
incomparable, which leads to `findBestSolutions` erasing all of them
while trying to compute best "partial" solution, which is incorrect.
Resolves: rdar://problem/42678836
Technically, these operations belong in the ObjectiveC module, where NSObject
is defined. Keep them there. However, we need to build the mock ObjectiveC
overlay with `-disable-objc-attr-requires-foundation-module` now.
...and collapse StaticVar/ClassVar and StaticLet/ClassLet into
StaticProperty/ClassProperty.
"var" and "let" aren't great nouns to use in diagnostics to begin with,
especially alongside semantic terms like "instance method". Focus on
the type vs. non-type aspect instead with "property", which better
matches how people talk about member vars (and lets) anyway.
This builds on initial commit which added `RelabelArguments` fix
to the solver that only supported `missingLabels` at that moment,
but now it supports all three posibilities - missing/extraneous and
incorrect labels.
When we determine that an optional value needs to be unwrapped to make
an expression type check, use notes to provide several different
Fix-It options (with descriptions) rather than always pushing users
toward '!'. Specifically, the errors + Fix-Its now looks like this:
error: value of optional type 'X?' must be unwrapped to a value of
type 'X'
f(x)
^
note: coalesce using '??' to provide a default when the optional
value contains 'nil'
f(x)
^
?? <#default value#>
note: force-unwrap using '!' to abort execution if the optional
value contains 'nil'
f(x)
^
!
Fixes rdar://problem/42081852.
The diagnostic when a user attempts to pass an argument requiring an implicit conversion (e.g. declared as a subclass, type conforming to protocol, etc.) to an inout parameter seems to be confusing for users—see e.g. SR-8155, SR-8148. This change replaces it with a more specific diagnostic which clearly suggests a solution. It also includes a fix-it suggesting the user change the type of the original variable if it’s a local with a simple type signature.
For `use(self.init())`, target of RebindSelfInConstructorExpr should be
call expression instead of paren expression.
rdar://problem/41416911
Possibly: rdar://problem/41593987
`finish{Array,Dictionary}Expr` currently invoke `cs.cacheExprTypes` after building their semantic exprs, which in a nested collection expression, immediately undoes the type changes done by this peephole, leading to crashes due to inconsistencies in the AST later. rdar://problem/41040820
The storage kind has been replaced with three separate "impl kinds",
one for each of the basic access kinds (read, write, and read/write).
This makes it far easier to mix-and-match implementations of different
accessors, as well as subtleties like implementing both a setter
and an independent read/write operation.
AccessStrategy has become a bit more explicit about how exactly the
access should be implemented. For example, the accessor-based kinds
now carry the exact accessor intended to be used. Also, I've shifted
responsibilities slightly between AccessStrategy and AccessSemantics
so that AccessSemantics::Ordinary can be used except in the sorts of
semantic-bypasses that accessor synthesis wants. This requires
knowing the correct DC of the access when computing the access strategy;
the upshot is that SILGenFunction now needs a DC.
Accessor synthesis has been reworked so that only the declarations are
built immediately; body synthesis can be safely delayed out of the main
decl-checking path. This caused a large number of ramifications,
especially for lazy properties, and greatly inflated the size of this
patch. That is... really regrettable. The impetus for changing this
was necessity: I needed to rework accessor synthesis to end its reliance
on distinctions like Stored vs. StoredWithTrivialAccessors, and those
fixes were exposing serious re-entrancy problems, and fixing that... well.
Breaking the fixes apart at this point would be a serious endeavor.
