QA: scan the Enzyme and Mooncake extensions - #82
Merged
ChrisRackauckas merged 1 commit intoAug 1, 2026
Conversation
ExplicitImports only analyzes an extension module when `Base.get_extension` returns it, which requires the extension's triggers to be loaded. The QA environment loaded no weakdeps, so neither `FunctionWrappersWrappersEnzymeExt` nor `FunctionWrappersWrappersMooncakeExt` was checked at all. Add Enzyme, EnzymeCore and Mooncake to `test/qa/Project.toml` (compat mirroring the root Project.toml) and `using` them in `qa.jl`. Both extensions are now covered. The new findings in the Enzyme extension are fixed at the source rather than ignored: the blanket `using Enzyme` / `using EnzymeCore` / `using EnzymeCore.EnzymeRules` become explicit imports, and the `inactive_type` definitions go through `EnzymeRules` directly instead of the `EnzymeCore.EnzymeRules` path. This also drops the two "both EnzymeRules and Enzyme export ..." ambiguity warnings emitted when the extension loaded. The remaining findings are AD rule-authoring interfaces with no public spelling (EnzymeRules' extension points, Mooncake's rule API) plus `Core.Typeof`, and are ignored with a comment naming the owner. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
ChrisRackauckas
marked this pull request as ready for review
August 1, 2026 08:53
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.
Please ignore this PR until it has been reviewed by @ChrisRackauckas.
What this fixes
run_qaruns ExplicitImports' checks over the package module and its submodules.ExplicitImports does know about extensions — it reads the
[extensions]tableout of
Project.toml— but it skips any extension for whichBase.get_extension(mod, ext)returnsnothing, and an extension module onlyexists once its triggers are loaded. The QA environment loaded no weakdeps, so
neither
FunctionWrappersWrappersEnzymeExtnorFunctionWrappersWrappersMooncakeExtwas being checked at all.Adding
Enzyme,EnzymeCoreandMooncaketotest/qa/Project.toml(compatmirroring the root
Project.toml) andusingthem intest/qa/qa.jlputs bothextensions under QA.
Coverage
FunctionWrappersWrappersEnzymeExt,FunctionWrappersWrappersMooncakeExt.environment, so there are no remaining unscanned extensions.
Fixed at the source (not ignored)
no_implicit_importsflagged the Enzyme extension for relying onusing Enzyme/
using EnzymeCore/using EnzymeCore.EnzymeRulesand then referring toEnzyme,EnzymeCore,EnzymeRules,Const,Duplicated,BatchDuplicated,Forward,ForwardWithPrimal. Those became explicit imports:EnzymeRulesis imported from the submodule that owns it rather than fromEnzymeCore(which does not export it), and the threeinactive_typedefinitions now go through
EnzymeRules.inactive_typeinstead of theEnzymeCore.EnzymeRules.inactive_typepath. Side benefit: this removes the twowarnings that were printed every time the extension loaded.
The Mooncake extension needed no source changes.
Ignore entries added
All of these are AD rule-authoring interfaces: the names a package must use to
teach an AD backend about a new callable, which the backend documents but has not
declared
public. There is no public spelling for any of them.all_qualified_accesses_are_public:forward,augmented_primal,reverse,inactive_type,strong_zeroEnzymeCore.EnzymeRulesEnzymeRulesexports the config accessors (needs_primal,overwritten,runtime_activity, ...) but not these extension points.build_rrule,rrule!!,tangent_type,primalMooncakevalue_and_gradient!!,prepare_gradient_cache,Config,Dual, ...); the entire rule API is documented-but-not-public.TypeofCoretypeofis wrong for arguments that are themselves types, and there is noBaseequivalent.all_explicit_imports_are_public:@is_primitive,CoDual,MinimalCtx,NoRData,NoTangent,fdata,zero_tangent— same Mooncake rule API as above.The pre-existing
:FunctionWrapperignore is unchanged. No check was disabled andnothing was marked broken.
Local runs
QA on the LTS (Julia 1.10.11) — the two public-API checks are skipped there by
SciMLTesting:
QA on Julia 1.12.6, where
all_qualified_accesses_are_publicandall_explicit_imports_are_publicalso run:Because the Enzyme extension's source changed, both AD groups were re-run on 1.10:
Runic 1.7.0 reports the touched files clean. No
Manifest.tomlis committed.