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

ERROR: TypeError: in <:, expected Type, got Vararg{Pair{String, String}} #114

Closed
fingolfin opened this issue Jan 6, 2021 · 13 comments · Fixed by #118
Closed

ERROR: TypeError: in <:, expected Type, got Vararg{Pair{String, String}} #114

fingolfin opened this issue Jan 6, 2021 · 13 comments · Fixed by #118

Comments

@fingolfin
Copy link
Contributor

fingolfin commented Jan 6, 2021

I as trying to use SnoopCompile on CxxWrap (see JuliaInterop/CxxWrap.jl#278 for my tiny progress so far; any feedback there from experts is of course welcome ;-) ) and run into the following issue. I am reporting it here since it seems to be in Cthulhu.jl code only, but perhaps that wrong, sorry in that case.

Here is what I did and the error:

$ julia-master
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.7.0-DEV.219 (2021-01-05)
 _/ |\__'_|_|_|\__'_|  |  Commit 399f8ba175* (0 days old master)
|__/                   |

(@v1.7) pkg> status
Status `~/.julia/environments/v1.7/Project.toml`
  [1f15a43c] CxxWrap v0.11.0
  [aa65fe97] SnoopCompile v2.2.1
  [e2b509da] SnoopCompileCore v2.2.1

julia> using SnoopCompileCore

julia> invalidations = @snoopr using CxxWrap;

julia> length(invalidations)
8226

julia> using SnoopCompile

julia> trees = invalidation_trees(invalidations);

julia> method_invalidations = trees[end];

julia> root = method_invalidations.backedges[end]
MethodInstance for String(::AbstractString) at depth 0 with 509 children

julia> ascend(root)
ERROR: TypeError: in <:, expected Type, got Vararg{Pair{String, String}}
Stacktrace:
  [1] stripType(typ::Any)
    @ Cthulhu ~/.julia/packages/Cthulhu/dG9TN/src/backedges.jl:58
  [2] nonconcrete_red(typ::Any)
    @ Cthulhu ~/.julia/packages/Cthulhu/dG9TN/src/backedges.jl:60
  [3] show_tuple_as_call(highlighter::Any, io::IOContext{IOBuffer}, name::Symbol, sig::Type, demangle::Bool, kwargs::Nothing)
    @ Cthulhu ~/.julia/packages/Cthulhu/dG9TN/src/backedges.jl:35
  [4] show_tuple_as_call(highlighter::Any, io::IOContext{IOBuffer}, name::Symbol, sig::Type)
    @ Cthulhu ~/.julia/packages/Cthulhu/dG9TN/src/backedges.jl:4
  [5] callstring(io::IOBuffer, mi::SnoopCompile.InstanceNode)
    @ Cthulhu ~/.julia/packages/Cthulhu/dG9TN/src/backedges.jl:95
  [6] treelist!(parent::FoldingTrees.Node{Cthulhu.Data{Core.MethodInstance}}, io::IOBuffer, mi::SnoopCompile.InstanceNode, indent::String, visited::Base.IdSet{Core.MethodInstance})
    @ Cthulhu ~/.julia/packages/Cthulhu/dG9TN/src/backedges.jl:124
  [7] treelist!(parent::FoldingTrees.Node{Cthulhu.Data{Core.MethodInstance}}, io::IOBuffer, mi::SnoopCompile.InstanceNode, indent::String, visited::Base.IdSet{Core.MethodInstance})
    @ Cthulhu ~/.julia/packages/Cthulhu/dG9TN/src/backedges.jl:126
  [8] treelist(mi::SnoopCompile.InstanceNode)
    @ Cthulhu ~/.julia/packages/Cthulhu/dG9TN/src/backedges.jl:117
  [9] ascend(mi::SnoopCompile.InstanceNode)
    @ Cthulhu ~/.julia/packages/Cthulhu/dG9TN/src/Cthulhu.jl:285
 [10] top-level scope
    @ REPL[11]:1

@timholy
Copy link
Member

timholy commented Jan 6, 2021

The Vararg change on 1.7 hasn't propagated to many packages that reach into Julia's internals. A PR would be great, but if you're not up for that you can either twiddle your thumbs until someone fixes it or use release-1.6 in the meantime.

@fingolfin
Copy link
Contributor Author

fingolfin commented Jan 6, 2021

I am not sure I understand: where does this need to be fixed? In Cthulhu or in CxxWrap?

@timholy
Copy link
Member

timholy commented Jan 6, 2021

Cthulhu. Basically, 1.7 broke Cthulhu. It works on 1.6.

@fingolfin
Copy link
Contributor Author

For future reference, this is about the effects of JuliaLang/julia#38136

I'd like to help, and am now looking at the code, but it's (for me) not exactly self-explaining; in particular, the intent of various functions is unclear, making it hard to guess what the right way to adjust things is.

So for the immediate error here, stripType presumably needs to be adjusted, as the error occurs in there -- or the mistake is that stripType is called in the first place.

If stripType needs to be adjusted... then I am still not sure how so, as I don't know what the intent of stripType is?

Beyond that, it baffles me is Vararg{Pair{String, String}} <: Type now produces an error -- seemingly indicating that the VarArg isn't a type anymore?

So perhaps the deeper problem then is that Vararg apparently is not a type anymore? Comparing https://docs.julialang.org/en/v1/base/base/#Core.Vararg and https://docs.julialang.org/en/v1.7-dev/base/base/#Core.Vararg I notice in the top line that Core.Vararg changed from "type" to "constant"; but the text still says "The type Vararg{T,N} ". So it seems to me that at least one of the following holds:

  1. there is a bug and Vararg{Pair{String, String}} should be a type after all
  2. the above documentation needs to be fixed for 1.7
  3. I am misunderstanding something (quite likely :-) ).

@fingolfin
Copy link
Contributor Author

I hope it is not inappropriate for me to tag @Keno here, but since he made those Vararg changes to Julia, he might be in the best position to answer the above?

@timholy
Copy link
Member

timholy commented Jan 8, 2021

That would be great, but I'm sure we can figure it out. I am swamped by yet new SnoopCompile-related analyses (really excited about a new idea I want to try...) and the fact that I can continue to work on 1.6 is a disincentive for me to fix this...

@timholy
Copy link
Member

timholy commented Jan 13, 2021

Beyond that, it baffles me is Vararg{Pair{String, String}} <: Type now produces an error -- seemingly indicating that the VarArg isn't a type anymore?

Isn't that almost precisely the title of JuliaLang/julia#38136?

@fingolfin
Copy link
Contributor Author

If that's what it says, great; I must admit that the role of DataType still is a bit fuzzy to me because of what its docstring says; I used to think it was the "type of types", but the "DataType represents explicitly declared types that have names, explicitly declared supertypes, and, optionally, parameters." which to me reads as if "but" follows, something like "... but there are other types". If that's wrong and my initial simpler assumption is true after all, I am glad to hear that!

But then I still think the manual is wrong for stating "The type Vararg{T,N} ..." ?

@timholy
Copy link
Member

timholy commented Jan 13, 2021

If it says that in the 1.7 manual, yes, that should perhaps be changed. I don't know which spot you're referring to so I can't easily check.

@timholy
Copy link
Member

timholy commented Jan 13, 2021

but there are other types

On 1.6 (I don't have 1.7 locally):

julia> subtypes(Type)
4-element Vector{Any}:
 Core.TypeofBottom
 DataType
 Union
 UnionAll

and then there's the confusing fact that Type{T} is a DataType.

@fingolfin
Copy link
Contributor Author

Indeed that's confusing:

julia> Type{Type} isa DataType
true   # as you wrote....

julia> supertypes(DataType)
(DataType, Type{T}, Any)    # whaaaat?!

Thanks for teaching me about subtypes ;-) I immediately learned that Any is a subtype of itself (which ... kinda makes some sense, perhaps, I guess.... my head hurts... but I guess that's what I get for getting involved with Cthulhu... ;-)

@fingolfin
Copy link
Contributor Author

As for the documentation, I filed JuliaLang/julia#39239

@timholy
Copy link
Member

timholy commented Jan 14, 2021

I immediately learned that Any is a subtype of itself (which ... kinda makes some sense, perhaps, I guess.... my head hurts.

😄. Everything gets easier when you start thinking of types in terms of sets. Int is a set with one object in it, Integer is a set with several (and expandable to more). Despite the notation, :< is equivalent to the set-theoretic ⊆ rather than strict ⊂. typeintersect is just set-intersection.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants