Reach the AutoDePSpecialize wrappers through public APIs - #1124
Draft
ChrisRackauckas-Claude wants to merge 2 commits into
Draft
Reach the AutoDePSpecialize wrappers through public APIs#1124ChrisRackauckas-Claude wants to merge 2 commits into
ChrisRackauckas-Claude wants to merge 2 commits into
Conversation
This was referenced Jul 28, 2026
The NonlinearSolveBase QA group fails on `master` with two
`ExplicitImports.NonPublicQualifiedAccessException`s in the ForwardDiff
extension, and two more in NonlinearSolveBase itself that the first pair was
masking. Rather than reconstruct the same objects through indirect public
surface, promote each name at its owning package and use it.
- `FunctionWrappersWrappers.SingleCacheStorage` plus the raw
`FunctionWrappersWrapper{FW, P, CS}(fwt, cs)` inner constructor become the
public `FunctionWrappersWrapper(fwt; policy)` tuple constructor, which exists
for exactly this inferrability case. It yields the identical concrete wrapper
type, so the norecompile path is unchanged. Requires
FunctionWrappersWrappers 1.11.
- `SciMLBase.has_sys` and `SciMLBase.ImmutableNonlinearProblem` are public as of
SciMLBase 3.41, so the guards in `maybe_opaque_wrap` keep their exact
semantics. `ImmutableNonlinearProblem` comes off the ExplicitImports ignore
list.
- `wrapfun_iip_opaque` is NonlinearSolveBase's own extension point, overloaded
in its own extension exactly like `wrapfun_iip`. It joins `wrapfun_iip` as an
explicit import and in the same ignore entry, which already documents this
category.
`RespecializeParams.wrap_void_opaque` needed nothing: it is already exported and
documented, and ExplicitImports never flagged it.
Adds a direct dual-call regression test for the opaque wrapper's Jacobian
signature, the shape AD actually reaches.
Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Reverts `_make_fww_iip` to its `master` form. With FunctionWrappersWrappers
1.11.0 registered, `SingleCacheStorage` is public, so the original code passes
the non-public-access check unchanged — rebuilding the wrapper through the
keyword constructor was never necessary.
It was also the wrong trade. The explicit `{FW, P, CS}(fwt, cs)` form fixes the
wrapper type from type parameters alone, while the keyword form derives `CS`
from `_make_cache_storage(cache)` and so leans on constant propagation through a
keyword-argument frame to stay concrete. Nothing on the norecompile path should
depend on that holding.
Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
ChrisRackauckas-Claude
force-pushed
the
agent/public-fww-path-nlsbase
branch
from
July 29, 2026 10:02
2994a92 to
fb18709
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Supersedes #1121. Closes #1118.
Summary
#1121 removed the
ExplicitImportsviolations by reconstructing the same objects through indirect public surface — derivingSingleCacheStorage's type by reflecting on a throwawayFunctionWrappersWrapper, swappingwrap_void_opaquefor a reuse ofwrapfun_iip, and substitutingSII.all_symbolsforhas_sys. This takes the other route: promote each name at its owning package and then just use it.The starting point was a local QA run on clean
master, which reports four non-public accesses, not the two in #1118 —ExplicitImportsstops at the first failing module, so the extension's violations were masking NonlinearSolveBase's own:FunctionWrappersWrappersThe extension builds its wrapper as
FunctionWrappersWrapper{typeof(fwt), AllowNonIsBits, typeof(cs)}(fwt, cs)withcs = SingleCacheStorage().SingleCacheStoragewas@publicand documented onmain(SciML/FunctionWrappersWrappers.jl#72) but sat in an unregistered 1.11.0.1.11.0 is now registered (General#162490), which makes that name public — so
_make_fww_iipneeds no change at all and is byte-identical tomaster. The only edit here is the compat floor.An earlier revision of this PR rewrote the call to go through the keyword constructor
FunctionWrappersWrapper(fwt; policy). That has been reverted. It was unnecessary, and it was the wrong trade: the explicit{FW, P, CS}(fwt, cs)form fixes the wrapper type from type parameters alone, whereas the keyword form derivesCSfrom_make_cache_storage(cache)and therefore leans on constant propagation through a keyword-argument frame to stay concrete. Nothing on the norecompile path should rest on that holding.SciML/FunctionWrappersWrappers.jl#79 is the matching follow-up: the two-argument inner constructor was reachable as public API (the type is exported) but was the only constructor of the type with no docstring. That PR documents it, so the whole called path is public and documented.
SciMLBasehas_syswas the only member of theAbstractSciMLFunctionfield-existence trait family that was neither public nor documented, andImmutableNonlinearProblemwas non-public whileImmutableODEProblemwas already@public. Both are addressed in SciML/SciMLBase.jl#1474, so the two guards inmaybe_opaque_wrapkeep their exact semantics rather than being reworded.This matters for
ImmutableNonlinearProblemspecifically: #1121 replacedprob isa NonlinearProblem || prob isa ImmutableNonlinearProblemwithproblem_type(prob) isa StandardNonlinearProblem, which is not equivalent —IntervalNonlinearProblemalso defaults toproblem_type = StandardNonlinearProblem()and is also<: AbstractNonlinearProblem, so it would newly pass the guard and then reachprob.u0, a field it does not have.RespecializeParamsNothing needed.
wrap_void_opaqueis already exported and documented in the released 1.x, andExplicitImportsnever flagged it — #1121's rewrite of that path was not required.wrapfun_iip_opaqueNonlinearSolveBase's own extension point, defined in
src/and overloaded in its own extension, exactly likewrapfun_iip. It becomes an explicit import and joinswrapfun_iipin the ignore entry that already covers this category ("NonlinearSolveBase (own internal)"). Making it public would commit a still-evolving internal (AutoDePSpecializereverse-mode support is a planned follow-up) to SemVer-stable public API.Validation
Rebased onto current
master(cb25573a). #1126 syncedNonlinearSolveBasedown to the registered 2.38.0, so the version here is now 2.38.1 rather than 2.39.1, and the compat floors were re-applied on top of master's.Only
SciMLBaseis developed — it is the one dependency still unregistered.FunctionWrappersWrappers1.12.0 andSciMLTesting2.6.1 resolve from the registry, which is exactly what CI will do:NonlinearSolveBase
QA— all four violations gone, group fully green:NonlinearSolveBase
Core— full group, zero failures:Runic 1.7.0
--checkon all changed files exits 0.Blocked on
SingleCacheStorageis public from 1.11.0 on, which the"1.11"floor here already accepts.treat_as_own = Union{Function, Type}[]fix from Preserve Aqua owned types in QA defaults SciMLTesting.jl#37. Verified by installing 2.6.1 from the registry and reading the source. Without it the QA group aborts before anyExplicitImportscheck runs.SciMLBase = "3.41"cannot resolve before then.Links