-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
Fix type instability in PresetTimeCallback
#230
Fix type instability in PresetTimeCallback
#230
Conversation
@maleadt @wsmoses your LLVM incompatibility has our CI shut down for now. How should I resolve this? |
Don't run on CI with |
Adding depwarns is different from using deprecated code. Why isn't there an update that just avoids the depwarn in your own dependency? |
Deprecated code triggers depwarns.
There is; you aren't using the latest version because of some incompatibility. |
I guess what we really want is |
Yes. That's really what we're looking for. |
So those functions are used to determine which version of LLVM is being used (later versions of LLVM have opaque pointers/newpm). Enzyme supports 1.6+. LLVM.jl only supports 1.10+ on latest versions (and older versions support 1.6). Thus on 1.6/7/8/9 Enzyme uses older LLVM.jl's. Since LLVM.jl only supports 1.10+, I presume @maleadt wants to eventually remove the other functionality, hence the depwarn. Since we support many different LLVM's/julia versions, we need to support both sides of the conditional so to speak. Once the LTS comes out and Enzyme drops 1.6-1.9 we can remove the code using that check. Not sure if there's a better soltion in the interim, but thats the tl;dr. |
close #225
This PR tries to solve the type instability in
PresetTimeCallback
start fromv3.2.0+
Checklist
contributor guidelines, in particular the SciML Style Guide and
COLPRAC.