-
-
Notifications
You must be signed in to change notification settings - Fork 610
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Issue 23010 - mixed in aliaseqs used as type don't initialize #14237
Conversation
|
Thanks for your pull request, @BorisCarvajal! Bugzilla references
Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "master + dmd#14237" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
It seems C++ header generation is better now using |
This is a no-op on my end. Incidentally I'm already doing the same as the added |
|
Moved some |
|
Dependant PR merged |
d89c129 to
b98cd4c
Compare
`TupleDeclaration` elements were inserted to the `members` array of current `ScopeDsymbol` but `TemplateMixin` declarations are already expanded in statement level and this confused DMD backend. After adding some code to insert tuple elements to `AggregateDeclaration.fields` and for parsing tuples in `toObjFile`, the code in question can be removed. No more hidden symbols (like `__tuple_field_0`) inside any `members` field.
TupleDeclarationelements were inserted to themembersarray ofcurrent
ScopeDsymbolbutTemplateMixindeclarations are alreadyexpanded in statement level and this confused DMD backend.
After adding some code to insert tuple elements to
AggregateDeclaration.fieldsand for parsing tuples in
toObjFile, the code in question can be removed.No more hidden symbols (like
__tuple_field_0) inside anymembersfield.