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

RFC: Teach intersection that 4 != 5 #39098

Closed
wants to merge 3 commits into from
Closed

RFC: Teach intersection that 4 != 5 #39098

wants to merge 3 commits into from

Conversation

Keno
Copy link
Member

@Keno Keno commented Jan 5, 2021

This one is very tricky, because we need to represent
"Vararg with at least n-elements", which we don't really
have a representation for. This just normalizes it to
Tuple{Vararg{T, N}} and stores an additional constraint
out of line that N must be greater or equal n. Then
if N is not resolved to an integer, we will normalize
this in a post processing step to e.g. Tuple{T, T, Vararg{T, N}}
(for n == 2). Eventually it might make sense to give Vararg
itself a lower bound. For now this seems to work ok, but
this code is very tricky, so we should PkgEval it before
merging.

Fix #39088

src/simplevector.c Outdated Show resolved Hide resolved
src/subtype.c Outdated Show resolved Hide resolved
src/subtype.c Outdated Show resolved Hide resolved
src/subtype.c Outdated Show resolved Hide resolved
src/jltypes.c Outdated Show resolved Hide resolved
src/simplevector.c Outdated Show resolved Hide resolved
@oscardssmith oscardssmith added this to the 1.7 milestone May 27, 2021
@oscardssmith oscardssmith added the bugfix This change fixes an existing bug label May 27, 2021
@vchuravy vchuravy removed this from the 1.7 milestone Jun 30, 2021
@vtjnash vtjnash added the needs pkgeval Tests for all registered packages should be run with this change label Aug 10, 2022
@vtjnash vtjnash marked this pull request as draft August 10, 2022 18:42
@vtjnash
Copy link
Sponsor Member

vtjnash commented Aug 10, 2022

I tried rebasing, but noted it currently has this particularly egregious error (both before and after rebasing):
typeintersect(NTuple, Tuple{Any,Vararg}) === NTuple{T,Vararg{T}} where T (gives Tuple{Any})

Keno and others added 3 commits August 30, 2022 13:30
This one is very tricky, because we need to represent
"Vararg with at least n-elements", which we don't really
have a representation for. This just normalizes it to
Tuple{Vararg{T, N}} and stores an additional constraint
out of line that `N` must be greater or equal `n`. Then
if `N` is not resolved to an integer, we will normalize
this in a post processing step to e.g. `Tuple{T, T, Vararg{T, N}}`
(for `n == 2`). Eventually it might make sense to give `Vararg`
itself a lower bound. For now this seems to work ok, but
this code is very tricky, so we should PkgEval it before
merging.
@vtjnash vtjnash marked this pull request as ready for review August 30, 2022 22:16
Comment on lines +2751 to +2759
if (vb->offset < 0) {
// Insert additional copies of the type to make up the
// `offset` difference.
*params = jl_svec_copy_resize(*params, jl_svec_len(*params) - vb->offset);
for (size_t i = 0; i < -vb->offset; ++i) {
jl_svecset(*params, pos + i, ii->T);
}
jl_svecset(*params, pos + -vb->offset, ii);
}
Copy link
Member

@N5N3 N5N3 Aug 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seems no reason to do this.
If vb->offset < 0, these parameters should have been intersected during intersect_tuple.
A simple example

julia> A = Tuple{Tuple{T,Vararg{T,N}},NTuple{N,T}} where {N,T}
Tuple{Tuple{T, Vararg{T, N}}, Tuple{Vararg{T, N}}} where {N, T}

julia> T = Tuple{Tuple,NTuple{4,Int}} where {M}
Tuple{Tuple, NTuple{4, Int64}}

julia> typeintersect(A, T)
Tuple{NTuple{6, Int64}, NTuple{4, Int64}}

The above example wont be fixed after removing this branch, but that should be a bug during re-intersection. (see 4dcce49)
My local log shows this PR gives wrong result within the 1st round intersection.

Copy link
Member

@N5N3 N5N3 Aug 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another bad regression.

julia> A = Tuple{Tuple{T,Vararg{T,N}},NTuple{N,T}} where {N,T}
Tuple{Tuple{T, Vararg{T, N}}, Tuple{Vararg{T, N}}} where {N, T}

julia> T = Tuple{Tuple,NTuple{M,Int}} where {M}
Tuple{Tuple, Tuple{Vararg{Int64, M}}} where M

julia> typeintersect(A, T)
Tuple{Tuple{Int64, Int64, Vararg{Int64, N}}, Tuple{}} where N

The first looks similar as the above example.

Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for looking, I started this before I noticed your PR, and was looking at getting that merged instead, then to revisit whether this fixed any additional cases

@N5N3 N5N3 added the types and dispatch Types, subtyping and method dispatch label Aug 31, 2022
N5N3 added a commit to N5N3/julia that referenced this pull request Aug 31, 2022
N5N3 added a commit to N5N3/julia that referenced this pull request Sep 1, 2022
@vtjnash vtjnash closed this Aug 31, 2023
@vtjnash
Copy link
Sponsor Member

vtjnash commented Aug 31, 2023

Looks like all examples here are fixed now. And #46604 exists for continued accuracy improvements that might be possible.

@vtjnash vtjnash deleted the kf/45 branch August 31, 2023 01:14
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 needs pkgeval Tests for all registered packages should be run with this change types and dispatch Types, subtyping and method dispatch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unreachable after Varargs change
6 participants