Uh oh!
There was an error while loading. Please reload this page.
Drop support for Base.tail() - #703
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@## main #703 +/- ##
==========================================
+ Coverage 93.38% 93.42% +0.03%
==========================================
Files 15 15 Lines 998 988 -10 ==========================================
- Hits 932 923 -9 + Misses 66 65 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
JamesWrigley
commented
Jan 28, 2026
The number of failures is a bit disturbing, but they don't seem related to this PR (and they also show up on other PRs). |
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
devmotion
commented
Jan 28, 2026
Sorry, I mis-clicked. IMO it would be great if we could remove these definitions. There are unfortunately preexisting test failures IIRC. I'll have a closer look tomorrow. |
devmotion
commented
Jan 29, 2026
This looks fine to me. The test errors seem unrelated, in many cases caused by Aqua tests and in particular without any reference to It would be good to fix the doctest failures though, such that we're able to build docs for the upcoming release. Can you update the doctests (see https://documenter.juliadocs.org/stable/man/doctests/#Fixing-Outdated-Doctests)? |
JamesWrigley
commented
Jan 29, 2026
Ah yeah sure, fixed them in eb83113. BTW one of them was using |
| julia> t = @thunk(3) | ||
| Thunk(var"#4#5"()) | ||
| Thunk(var"#2#3"()) |
There was a problem hiding this comment.
I'd suggest
| julia> t =@thunk(3) | |
| Thunk(var"#4#5"()) | |
| Thunk(var"#2#3"()) | |
| julia> t =@thunk(3); |
or a doctest filter. But I think removing the output is simpler.
devmotion
commented
Jan 30, 2026
Can you update the version number? |
JamesWrigley
commented
Jan 31, 2026
Sure, done in 10e0ec5. |
| name = "ChainRulesCore" | ||
| uuid = "d360d2e6-b24c-11e9-a2a3-2a2ae2dbcce4" | ||
| version = "1.26.0" | ||
| version = "1.26.1" |
There was a problem hiding this comment.
This is a breaking change - it will definitely break older ChainRules releases and it might break packages that define rules using Base.tail.
| version = "1.26.1" | |
| version = "2.0.0" |
There was a problem hiding this comment.
I also removed the compat bound in docs/Project.toml so that the docs will build. There's quite a few more failing tests now, I guess because downstream packages aren't compatible anymore.
There was a problem hiding this comment.
Making this a breaking change is really annoying though.
Can we see if anyone is using it?
I suspect they were not, since Base.tail isn't part of Base's public API.
Easy way to see if people are using it is to just release it with this as a nonbreaking change,
and then if people complain tag a bug fix that reverts the change.
Like it will break old ChainRules.jl releases, but only pretty old ones that there is no particular reason to be using, unless they are locked in a Manifest.toml.
But in that case the version of ChainRulesCore.jl is also going to be locked to an old version.
There was a problem hiding this comment.
It's annoying but it's the only way to avoid breaking existing releases, of ChainRules and possibly other packages.
SciML is making non-breaking releases that break existing versions of SciML and non-SciML packages quite regularly in my experience, and I think that's far more annoying than making a breaking release. Even if people would complain and a subsequent bug fix release would be made, there would still be a combination of package versions in the registry that is officially declared to be compatible but in fact isn't.
There was a problem hiding this comment.
Even if people would complain and a subsequent bug fix release would be made, there would still be a combination of package versions in the registry that is officially declared to be compatible but in fact isn't.
This is why Pkg should refuse to install things other than the latest patch release of a package (at least post 1.0.0)
But can imitate that by yanking prior ones.
I guess arguably Base.tail is part of the public API.
It wasn't when I wrote those overloads.
But it is now documented as public.
At the moment there is 283 direct reverse dependencies.
That is a lot to make do a update.
I guess dependabot will catch them though.
There was a problem hiding this comment.
Am I correct in thinking that all those direct dependents could use package extensions on ChainRules.jl instead?
There was a problem hiding this comment.
you are not correct.
ChainRules.jl is not something packages writing rules should depend on.
It's huge. It is just a collection of rules for Base + stdlibs.
Not a tool for rules authors.
Only AD packages should depend on that.
Admittedly that is less of a consideration with package extensions now.
In general I would just be shocked to find that any of them depend on this feature.
Calling tail on a ChainRulesCore Tangent is just pretty niche,
expecially if you are writing rules for things other than Tuples.
09cb407 to
23fb04cCompareJamesWrigley
commented
Feb 8, 2026
(bump) |
JamesWrigley
commented
Feb 19, 2026
Bump, just wondering when v2 is planned? No worries if there are some other things planned for v2 that this would have to wait for. |
ChrisRackauckas
commented
Feb 21, 2026
Yeah these invalidations seem to show up everywhere. |
JamesWrigley
commented
Mar 4, 2026
(bump) |
1 similar comment
JamesWrigley
commented
Mar 20, 2026
(bump) |
ChrisRackauckas
commented
Mar 29, 2026
I think to get this in, it would be best to have a PR that first fixes tests for master, then do this. But yes, this is quite required since this invalidation is pretty deadly. |
JamesWrigley
commented
Mar 29, 2026
I opened some PRs to add compat bounds. Could you unblock CI for JuliaArrays/StaticArrays.jl#1339? I'm looking into the FiniteDifferences failures (can't be related since this PR isn't out yet, but still). |
883f412 to
b8950d4Compare6b6f662 to
cc05f7fCompareJamesWrigley
commented
Mar 30, 2026
Ok, with a couple more fixes (d59d0ea) CI is in the green again. Caveat is that all of the integration tests are skipped because they don't have compat with v2, we'll have to go through all those after the release. |
ChrisRackauckas
commented
Mar 30, 2026
The fixing should be a separate PR from the breaking PR. |
JamesWrigley
commented
Mar 30, 2026
Why? They're separate commits. |
ChrisRackauckas
commented
Mar 30, 2026
We should probably put the release out which fixes tests as the last v1 release, and that should be reviewed and merged. That's completely separate from a v2 breaking change. |
JamesWrigley
commented
Mar 30, 2026
Ok, I made #706. |
JamesWrigley
commented
Apr 2, 2026
Getting there 😅 Rebased the PR now. We'll want to revert 24f913a once JuliaDiff/FiniteDifferences.jl#248 and JuliaArrays/StaticArrays.jl#1339 are released. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This causes invalidations and should not be needed anymore by the upstream ChainRules.
This causes invalidations and should not be needed anymore by ChainRules.jl since the rule that uses it: #576 (comment)
Was deleted in JuliaDiff/ChainRules.jl#680.
I ran this on the ChainRules.jl tests and saw a ton of failures locally (also seen in CI), but none that seem related to this change. Disclaimer: I have almost no understanding of this kind of thing 🙈
Fixes#576.
Fixes these invalidations seen in CurveFit.jl: