Small fixes for diagnostics with prepared overloads enabled #84821
Conversation
…ocator didn't change For a Bind constraint generated by a same-type requirement, we must preserve the locator so we need to record it like any other kind of constraint. This fixes a diagnostic regression with -solver-enable-prepared-overloads.
…ge() We want to re-prepare our overloads, since now they will contain fixes.
|
@swift-ci Please smoke test |
|
@swift-ci Please test source compatibility |
| // FIXME: Perhaps we should store the Constraint -> PreparedOverload mapping | ||
| // in a SolverStep or something? Mutating Constraint feels wrong. | ||
|
|
||
| void Constraint::setPreparedOverload(PreparedOverload *preparedOverload) { |
There was a problem hiding this comment.
sorry for the drive by, but out of curiosity: what is a 'prepared overload'?
There was a problem hiding this comment.
Generating type variables and constraints for a disjunction choice once only instead of every time the disjunction choice is attempted, to reduce instances of exponential space usage. It speeds up the “worst case” behavior of the solver by 10-20%.
There was a problem hiding this comment.
(And feel free to ask questions always!)
There was a problem hiding this comment.
thanks! i had noticed some earlier PRs float by using this terminology – this first one has more about the motivation. so IIUC this approach will cache some intermediary data structures used by the solver which previously were not reused. how does the space savings lead to such a performance speedup in the "worst case"? does the high memory use spill over into wasted time (idk much about how the memory 'arena' for the solver is set up)? or is it just the wasted time of recreating the same data structures repeatedly that is eliminated when caching them?
2 participants
No description provided.