Unexpected kwarg false-positive when using TypeVarTuple

[kdkavanagh]

Bug description

a @DataClass base defines a field, and two child classes both use
PEP 695 TypeVarTuple syntax (*Shape) with the TypeVarTuple forwarded in
the parent specialization (Middle[T, *Shape]). Pylint loses track of the
inherited field through the forwarded TypeVarTuple chain.

Likely related to #10972

from dataclasses import dataclass

@dataclass(frozen=True, kw_only=True)
class Base:
    value: str

@dataclass(frozen=True, kw_only=True)
class Middle[T, *Shape](Base):
    pass

@dataclass(frozen=True, kw_only=True)
class Upper[T, *Shape](Middle[T, *Shape]):
    pass

obj = Upper[str, int](value="hello")

Command used

pylint -vv

Pylint output

E1123: Unexpected keyword argument 'value' in constructor call

Expected behavior

No error raised

Pylint version

$ pylint --version
pylint 4.0.5                                                                                             
astroid 4.0.4                                                                                            
Python 3.12.6 (main, Oct  9 2024, 11:19:43) [GCC 13.2.0]

OS / Environment

No response

Additional dependencies

[MCharming98]

I think dataclass_transform fails to propagate inherited fields when a base class uses PEP 695 syntax (e.g., Middle[T, *Shape]). This happens because astroid cannot resolve the MRO when a TypeVarTuple is present in a base.

Critical Signals:

• In astroid/nodes/node_classes.py,_infer_sequence_helper fails when it hits a Starred node containing a TypeVarTuple. It expects an .elts attribute which is missing for this node type, triggering an InferenceError.
• ClassDef.mro() silently drops any base class that fails to infer.
• Because the MRO is incomplete, brain_dataclasses.py misses fields from parent classes during the transform.

Next Steps:

• Modify BaseContainer._infer_sequence_helper to explicitly handle TypeVarTuple within Starred nodes (either via placeholder or by yielding the node itself).
• Add a fallback in BaseContainer._infer to yield self if the helper raises an error, preventing total MRO collapse.

Note on this analysis

I’m currently developing Repellent AI, a specialized Root Cause Analysis (RCA) agent designed to reduce maintainer triage time. It recently achieved 88% accuracy on the SWE-bench Verified dataset.

I am testing on live issues like this one to validate the quality of the analysis. My goal is to provide helpful, actionable signals rather than automated noise. I'd love to hear if this level of detail is useful for you!