Commit Graph

7 Commits

Author SHA1 Message Date
Doug Gregor
b94a5c8dd4 Update a test case's expected output 2020-02-25 20:39:42 -08:00
Doug Gregor
8283a67648 Revert "Revert "Reimplement function builders as statement transformations."" 2020-01-21 10:07:20 -08:00
Doug Gregor
86c13d3c74 Revert "Reimplement function builders as statement transformations." 2020-01-17 15:52:49 -08:00
Doug Gregor
a49f0091cb [Constraint application] Skip error expressions when applying builders.
If we encountered an error, just skip it; there's nothing more to do.
2020-01-16 13:19:21 -08:00
Pavel Yaskevich
8bcc192591 [Diagnostics] Diagnose inability to infer (complex) closure return type 2019-12-19 12:16:30 -08:00
Pavel Yaskevich
94b4052321 [CSDiag] NFC: Remove all of the obsolete diagnoseGeneral*Failures logic 2019-12-03 12:07:16 -08:00
Pavel Yaskevich
addc2b06ab [ConstraintSystem] Introduce notion of constraint system phase
Some constraint transformations require knowledge about what state
constraint system is currently in e.g. `constraint generation`,
`solving` or `diagnostics` to make a decision whether simplication
is possible. Notable example is `keypath dynamic member lookup`
which requires a presence of `applicable fn` constraint to retrieve
some contextual information.

Currently presence or absence of solver state is used to determine
whether constraint system is in `constraint generation` or `solving`
phase, but it's incorrect in case of `diagnoseFailureForExpr` which
tries to simplify leftover "active" constraints before it can attempt
type-check based diagnostics.

To make this more robust let's introduce (maybe temporarily until
type-check based diagnostics are completely obsoleted) a proper
notion of "phase" to constraint system so it is always clear what
transitions are allowed and what state constraint system is
currently in.

Resolves: rdar://problem/57201781
2019-11-20 18:34:51 -08:00