stubgen: Fix generated dataclass __init__ signature

[hamdanal]

Fixes #16811

stubgen was swallowing default values for __init__ methods generated by the dataclass plugin making their signature incorrect. This is because the plugin does not include the argument's initializer in the generated signature. I changed it to include a dummy ellipsis so that stubgen can generate correct code.
I also fixed arguments added by the dataclass plugin with the invalid names * and ** to have the valid and unique names *generated_args and **generated_kwargs (with extra underscores to make them unique if necessary). This removes the need for the hack to special case them in stubgen and is less confusing for someone looking at them in a stub file.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[AlexWaygood]

I believe it's valid to use @dataclass in a stub file, and that if you do have @dataclass in a stub file, type checkers are meant to synthesize the generated __init__ method (and other generated methods) in the same way they do when they see dataclasses in .py files. Maybe the best behaviour here would be for stubgen not to add an __init__ method at all for dataclasses, if the original dataclass doesn't have an __init__ method? It would lead to simpler stubs

[hamdanal]

I believe it's valid to use @dataclass in a stub file, and that if you do have @dataclass in a stub file, type checkers are meant to synthesize the generated __init__ method (and other generated methods) in the same way they do when they see dataclasses in .py files. Maybe the best behaviour here would be for stubgen not to add an __init__ method at all for dataclasses, if the original dataclass doesn't have an __init__ method? It would lead to simpler stubs

You are right, that's why I changed stubgen to keep the dataclass decorator recently. The problem is that we cannot keep field assignments in the stub so we lose information that is usually inferred from calls like a = field(init=False) (a is not part of the __init__ signature) or b = field(default_factory=list) (b is optional because it has a default value) which leads to the type checker generating wrong signature for __init__. It is safe to delete the generated method in simple cases (where there is no loss of information due to absence of field() calls) later though.

[AlexWaygood]

The problem is that we cannot keep field assignments in the stub so we lose information that is usually inferred from calls like a = field(init=False) (a is not part of the __init__ signature) or b = field(default_factory=list) (b is optional because it has a default value) which leads to the type checker generating wrong signature for __init__. It is safe to delete the generated method in simple cases (where there is no loss of information due to absence of field() calls) later though.

I see -- that makes sense, thanks!

[JelleZijlstra]

There is one aspect of the issue that isn't fixed by this PR: the __init__ parameters still don't have types. That can wait for another PR, though.

[hamdanal]

There is one aspect of the issue that isn't fixed by this PR: the __init__ parameters still don't have types. That can wait for another PR, though.

Including these types is a step into uncharted territory for stubgen as these types are inferred and stubgen doesn’t know how to handle them yet. I tried a little bit to include them before submitting the PR but they require some non trivial work (e.g. adding new imports for the inferred annotations and handling name collisions) so I left them out for now.
Note that there is a feature request already for stubgen including inferred types here #3475.