-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
subtype: more conservative intersection of triangular variables #49591
Conversation
When a variable is used triangularly, we need to be careful not to propagate the lower bound implied by the other side to the upper bound implied by the invariant usage of the value--that is only legal when we are intersecting a variable that is used diagonally. Fix #49578
@nanosoldier |
Your package evaluation job has completed - possible new issues were detected. |
That seemed to go unusually well for PkgEval. Shall we merge this? @nanosoldier |
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. |
Looks like inference allocated slightly more, but performance was mostly unchanged otherwise for runtime |
This is breaking https://github.com/Nemocas/AbstractAlgebra.jl (see the Pkgeval log: https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/741caec_vs_d82ae9e/AbstractAlgebra.primary.log). It seems some variables have now type |
Out of curiosity, what's the point of that inner constructor (https://github.com/Nemocas/AbstractAlgebra.jl/blob/573c81e7d457affc9917656d6cb191e357a26a91/src/generic/GenericTypes.jl#L1477-L1479). Without it, things would still work (even with this PR), no? |
No, it cannot work without that constructor. I don't see how it could. |
The order of the fields could be corrected, then it looks to me like all of those constructors could be deleted |
Yes, indeed. I just tried this, but it still errors with this PR here. Not sure if these comments were recommended as a "fix"? |
More minimally then, just remove the unnecessary uses of |
When a variable is used triangularly, we need to be careful not to propagate the lower bound implied by the other side to the upper bound implied by the invariant usage of the value--that is only legal when we are intersecting a variable that is used diagonally.
This is attempting to be a fairly conservative fix. If this works, I think we can revisit simplifying the constraintkind, and then revisit recovering the accuracy lost in this initial phase of the change.
Fix #49578