Changes between Version 4 and Version 5 of DeferErrorsToRuntime


Ignore:
Timestamp:
Dec 21, 2011 11:06:26 AM (4 years ago)
Author:
dreixel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DeferErrorsToRuntime

    v4 v5  
    3838== Implementation details ==
    3939
    40 To do.
     40The first step is to make sure that `TcUnify` does not ever fail with a type
     41error; instead, we call `uType_defer` to defer the unification to the constraint
     42solver.
     43
     44In the constraint solver, we call `reportUnsolved` with any remaining unsolved
     45constraints. At this stage, if we are not deferring errors, we simply make the
     46errors for each unsolved constraint and throw them. If we are deferring errors,
     47we make the errors for each constraint and then set the evidence binder of each
     48unsolved constraint to be a runtime error that emits the type error message we
     49just created. This is done by `reportTidyWanteds` and `deferCt` in
     50`typecheck/TcErrors`. Note that `reportTidyWanteds` has some shuffling to do,
     51because when we are not deferring errors we group certain errors, or we don't
     52report all the errors. But when we are deferring we really want to have
     53(at least) one error for every coercion.
     54
     55=== Error messages ===
     56
     57For simplicity, we defer errors from `TcUnify` to the constraint solver even
     58if `-fwarn-type-errors` is not on; in that case, we will simply fail in the
     59constraint solver, rather than directly in the unifier.
     60
     61This means that some type error messages change, even without `-fwarn-type-errors`.
     62In particular, many tests from the testsuite need to have their output adapted.
     63