[For maintainers] Suggested jobs to run (before merge)

run-slow: audioflamingo3, auto, lasr, phi4_multimodal, pix2struct

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Thanks for the MRO walk, which fixes the inheritance case I reported.

One small follow-up: @zucchini-nlp suggested in the issue thread allowing an explicit attributes override with auto-detection as fallback. Doesn't seem to be in this PR. Would it be worth adding on top of the MRO walk?

@classmethod
def get_attributes(cls):
    if "attributes" in cls.__dict__ and cls.attributes is not None:
        return list(cls.attributes)
    # ... existing MRO-based detection ...

Two concrete reasons:

1. The original case in this issue is still broken with the MRO walk alone.

My actual code uses a custom (non-HF) tokenizer:

class ActionTokenizerMixin:
    def __init__(self, *args, action_tokenizer: Optional[BaseActionTokenizer] = None, **kwargs):
        ...

BaseActionTokenizer is not a PreTrainedTokenizerBase. After the MRO walk, action_tokenizer would be auto-detected as a sub-processor (it contains "tokenizer"), then check_argument_for_proper_class would reject it at processing_utils.py#L720-L723:

if not isinstance(argument, proper_class):
    raise TypeError(
        f"Received a {type(argument).__name__} for argument {argument_name}, "
        f"but a {class_name} was expected."
    )

An explicit attributes = [...] override is the only way to opt this parameter out of auto-detection without losing the MRO behavior for everything else.

2. Substring-based detection already needs core-level carve-outs.

audio_tokenizer matches the "tokenizer" substring but isn't actually a tokenizer (it's a DacModel per MODALITY_TO_BASE_CLASS_MAPPING), so it's currently excluded from the auto-detect flow at six places in processing_utils.py:

• L611-L618: bypass in __init__
• L768-L774: Special case branch in to_dict
• L1146-L1157: separate file path in from_pretrained
• L1444, L1455, L1458: three continue skips in get_attributes

It's the only such case today, but any future component whose name happens to overlap a modality substring (such as the non-HF custom tokenizer in this issue) will hit the same shape of problem. An explicit attributes override pushes that decision to the model file instead of patching processing_utils.py again.

Happy to open a separate PR for this on top of yours.