21

CC @xedin

23

This is a bug in TypeChecker::isDeclRefinementOf, the position shouldn't matter but isDeclRefinementOf incorrectly considered overload that returns T to be a refinement of the one that returns T.D. I have a fix for this - [CSStep] Add a nullptr check to `IsDeclRefinementOfRequest::evaluate` by xedin · Pull Request #70956 · apple/swift · GitHub

9 Likes
24

I hate to say this but isn’t that a source-breaking change? Even if it’s code that never should have worked, the conflicting decls are potentially far away from the use site.

1 Like
25

Speaking as a constraint system engineer (and not on behalf of the Language Steering Group): Pretty much any tweak or bug fix to the constraints system performance heuristics is source breaking in some obscure way. The engineers who actively work on the constraint system have been dealing with this for years, and unless we discover that the impact of the source break is widespread through source compatibility testing, we generally do not consider a bug fix like this to rise to the level of a language evolution proposal / upcoming feature to stage in the source breaking change, because it's code that never should have worked, and indeed it did not work in compiler versions <= 5.4 (IIRC I implemented the "declaration refinement" performance heuristic, which inadvertently allowed this code, in Swift 5.5).

12 Likes