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

Reflection functions should handle UnionAll #20872

Closed
yuyichao opened this issue Mar 3, 2017 · 5 comments
Closed

Reflection functions should handle UnionAll #20872

yuyichao opened this issue Mar 3, 2017 · 5 comments
Assignees
Labels
domain:types and dispatch Types, subtyping and method dispatch

Comments

@yuyichao
Copy link
Contributor

yuyichao commented Mar 3, 2017

From #20869

julia> foo{N}(::Val{N}, ::Type{Val{N}}) = true
foo (generic function with 1 method)

julia> Method[m[3] for m in Base._methods_by_ftype(Tuple{typeof(foo),Val{N},Type{Val{N}}} where N, -1, typemax(UInt))]
1-element Array{Method,1}:
 foo(::Val{N}, ::Type{Val{N}}) where N in Main at REPL[1]:1

julia> methods(foo, Tuple{Val{N},Type{Val{N}}} where N)
ERROR: type UnionAll has no field parameters
Stacktrace:
 [1] to_tuple_type(::Any) at ./reflection.jl:466
 [2] methods(::Any, ::Any) at ./reflection.jl:582
@ssfrr
Copy link
Contributor

ssfrr commented Jun 24, 2017

For some user-facing context - this issue is causing errors to be thrown whenever Atom tries to run auto-completion if PlotlyJS is loaded, using 0.6.0 (unless there's something weird on my machine specifically). Is there a fix/backport that seems likely soon, or would it make sense to try to work around it in Atom or PlotlyJS?

@pfitzseb @MikeInnes @sglyon

@vtjnash
Copy link
Sponsor Member

vtjnash commented Jun 25, 2017

also related to #22051?

@sglyon
Copy link
Contributor

sglyon commented Jun 26, 2017

Hey @ssfrr I've noticed it too, but didn't narrow it down to only arising after loading PlotlyJS. That's super weird.

The good news is that it looks like @pfitzseb made a fix in CodeTools.jl. have you tried that yet?

@tkoolen
Copy link
Contributor

tkoolen commented Aug 8, 2017

This issue partially breaks DocStringExtensions on 0.6: JuliaDocs/DocStringExtensions.jl#32.

@tkoolen
Copy link
Contributor

tkoolen commented Aug 9, 2017

See JuliaDocs/DocStringExtensions.jl#38 for my workaround for this issue in DocStringExtensions.

As I was implementing this workaround, I realized that DocStringExtensions' getmethods! function was already working around a couple of corner cases of Base.methods that one could argue aren't handled properly; I was merely adding another. Should DocStringExtensions.getmethods just form the basis for a new Base.methods implementation?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:types and dispatch Types, subtyping and method dispatch
Projects
None yet
Development

No branches or pull requests

7 participants