Skip to content
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

Merged
merged 1 commit into from
May 5, 2023

Conversation

vtjnash
Copy link
Member

@vtjnash vtjnash commented May 2, 2023

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

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
@vtjnash vtjnash added types and dispatch Types, subtyping and method dispatch bugfix This change fixes an existing bug needs pkgeval Tests for all registered packages should be run with this change labels May 2, 2023
@N5N3
Copy link
Member

N5N3 commented May 2, 2023

@nanosoldier runtests()

@nanosoldier
Copy link
Collaborator

Your package evaluation job has completed - possible new issues were detected.
A full report can be found here.

@vtjnash vtjnash removed the needs pkgeval Tests for all registered packages should be run with this change label May 2, 2023
@vtjnash
Copy link
Member Author

vtjnash commented May 2, 2023

That seemed to go unusually well for PkgEval. Shall we merge this?

@nanosoldier runbenchmarks(!"scalar", vs=":master")

@nanosoldier
Copy link
Collaborator

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

@vtjnash
Copy link
Member Author

vtjnash commented May 3, 2023

Looks like inference allocated slightly more, but performance was mostly unchanged otherwise for runtime

@thofma
Copy link
Contributor

thofma commented May 4, 2023

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 Vector{Any}, which then results in a method error.

@KristofferC
Copy link
Member

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?

@thofma
Copy link
Contributor

thofma commented May 4, 2023

No, it cannot work without that constructor. I don't see how it could.

@vtjnash
Copy link
Member Author

vtjnash commented May 4, 2023

The order of the fields could be corrected, then it looks to me like all of those constructors could be deleted

@thofma
Copy link
Contributor

thofma commented May 4, 2023

Yes, indeed. I just tried this, but it still errors with this PR here. Not sure if these comments were recommended as a "fix"?

@vtjnash
Copy link
Member Author

vtjnash commented May 5, 2023

More minimally then, just remove the unnecessary uses of {T}

@vtjnash vtjnash merged commit 9b7d88b into master May 5, 2023
@vtjnash vtjnash deleted the jn/49578 branch May 5, 2023 19:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfix This change fixes an existing bug types and dispatch Types, subtyping and method dispatch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Regression in nightly: dispatch depends on order runtime calls, not signatures
5 participants