-
Notifications
You must be signed in to change notification settings - Fork 36
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
Invalidations #121
Comments
I can't remember if |
It looks like we could instead define EDIT: actually it looks like the invalidations still happen if we just define |
Yeah, the problem is that it calls I think the 1.6 backport window may still be sufficiently open to get this in, but we'll see. |
Yes, if that improves compilation and doesn't break anything here then 👍 I like it. |
I guess we could just not subtype |
Resolves JuliaArrays/ArrayInterface.jl#121. There is a cost, but hopefully there's no strong need to supply `maxlog` using whacky subtypes of Integer.
I think you probably want to subtype The logging framework has been wickedly untyped; it's one of the few places where we've had to resort to using Keep an eye on JuliaLang/julia#39689 |
Will do. Thank you. |
I think once upon a time we didn't define I could live with something like: int(x) = Int(x)
int(::StaticInt{N}) = N if we didn't want to wait until Julia 1.7 for most users to be relieved of the invalidations. But taking out The list of invalidations also shows: 18: signature Tuple{Type{Int64}, Integer} triggered MethodInstance for var"#handle_message#2"(::Any, ::typeof(Base.CoreLogging.handle_message), ::Logging.ConsoleLogger, ::Base.CoreLogging.LogLevel, ::Any, ::Any, ::Any, ::Any, ::Any, ::Any) (772 children) So we do see it is a |
Note that we are probably moving most of this stuff to https://github.com/SciML/Static.jl. |
If it's all array traits, why not JuliaArrays? This stuff should be useful across many domains. |
I meant the |
Resolves JuliaArrays/ArrayInterface.jl#121. There is a cost, but hopefully there's no strong need to supply `maxlog` using whacky subtypes of Integer. (cherry picked from commit 67b9d4d)
…9689) Resolves JuliaArrays/ArrayInterface.jl#121. There is a cost, but hopefully there's no strong need to supply `maxlog` using whacky subtypes of Integer.
…9689) Resolves JuliaArrays/ArrayInterface.jl#121. There is a cost, but hopefully there's no strong need to supply `maxlog` using whacky subtypes of Integer.
Resolves JuliaArrays/ArrayInterface.jl#121. There is a cost, but hopefully there's no strong need to supply `maxlog` using whacky subtypes of Integer. (cherry picked from commit 67b9d4d)
I checked this to see how ready this might be to include in ImageCore. Here are the invalidations from this package on Julia 1.6-rc1:
Only the last one is bad, but it's pretty bad. (Among other things, it invalidates
Base.require
which means the next package to load has to recompile it.) The vulnerability arises in https://github.com/JuliaLang/julia/blob/b1fbe7f135f1b7b0f0c80a6484ea090eef1f1e72/stdlib/Logging/src/ConsoleLogger.jl#L104-L105; since all it knows is thatmaxlog isa Integer
, it's possible that the(::Type{T})(x::ArrayInterface.StaticInt{N}) where {T<:Integer, N}
method is applicable and more specific.The only really good fix I can see is to restrict
maxlog
support to specific integer types, like the ones Julia ships with. This would be a fix for Base but I am filing this here as a reminder. When working on a package it's worth checking this periodically as it could be a deal-breaker for inclusion in other things.The text was updated successfully, but these errors were encountered: