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

Regression: failure of TypeVar in recursive struct with NTuple field #55189

Closed
MilesCranmer opened this issue Jul 21, 2024 · 1 comment · Fixed by #55405
Closed

Regression: failure of TypeVar in recursive struct with NTuple field #55189

MilesCranmer opened this issue Jul 21, 2024 · 1 comment · Fixed by #55405
Labels
regression Regression in behavior compared to a previous version

Comments

@MilesCranmer
Copy link
Sponsor Member

MilesCranmer commented Jul 21, 2024

When using NTuple in a recursive type, there is a failure of TypeVars to apply:

julia> struct A{N}
           children::NTuple{N,A{N}}
       end

julia> fieldtypes(A{2})
(Tuple{A, A},)

However, this should be Tuple{A{2}, A{2}}.

Consider NTuple by itself:

julia> NTuple{2,Array{Float64,2}}
Tuple{Matrix{Float64}, Matrix{Float64}}

You can use this in structs if it is not recursive:

julia> struct A{N}
           children::NTuple{N,Array{Float64,N}}
       end

julia> fieldtypes(A{2})
(Tuple{Matrix{Float64}, Matrix{Float64}},)

However, if the type is recursive, the typevar fails to apply in the type parameters.

versioninfo():

Julia Version 1.10.4
Commit 48d4fd48430 (2024-06-04 10:41 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: macOS (arm64-apple-darwin22.4.0)
  CPU: 8 × Apple M1 Pro
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, apple-m1)
Threads: 6 default, 0 interactive, 3 GC (on 6 virtual cores)

Another potentially related failure for NTuple field types is #55076.


While this fails on 1.10.4, this works on 1.6.7.

@MilesCranmer MilesCranmer changed the title Failure of TypeVar in recursive struct with NTuple field Regression: failure of TypeVar in recursive struct with NTuple field Jul 21, 2024
@MilesCranmer
Copy link
Sponsor Member Author

This works on 1.6.7, so seems to be a regression:

julia> struct A{N}
           children::NTuple{N,A{N}}
       end

julia> fieldtypes(A{2})
(Tuple{A{2}, A{2}},)

On 1.7.3 it seems to infinitely hang.

Possibly also caused by #43306?

@nsajko nsajko added the regression Regression in behavior compared to a previous version label Jul 21, 2024
vtjnash added a commit that referenced this issue Aug 7, 2024
Comparing objects by `==` will happily answer nonsense for malformed
type comparisons, such as `unwrap_unionall(A) == A`. Avoid forming that
query. Additionally, need to recourse through Vararg when examining type
structure to make decisions.

Fix #55076
Fix #55189
vtjnash added a commit that referenced this issue Aug 7, 2024
Comparing objects by `==` will happily answer nonsense for malformed
type comparisons, such as `unwrap_unionall(A) == A`. Avoid forming that
query. Additionally, need to recourse through Vararg when examining type
structure to make decisions.

Fix #55076
Fix #55189
KristofferC pushed a commit that referenced this issue Aug 13, 2024
Comparing objects by `==` will happily answer nonsense for malformed
type comparisons, such as `unwrap_unionall(A) == A`. Avoid forming that
query. Additionally, need to recourse through Vararg when examining type
structure to make decisions.

Fix #55076
Fix #55189

(cherry picked from commit 32423a8)
lazarusA pushed a commit to lazarusA/julia that referenced this issue Aug 17, 2024
Comparing objects by `==` will happily answer nonsense for malformed
type comparisons, such as `unwrap_unionall(A) == A`. Avoid forming that
query. Additionally, need to recourse through Vararg when examining type
structure to make decisions.

Fix JuliaLang#55076
Fix JuliaLang#55189
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
regression Regression in behavior compared to a previous version
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants