-
-
Notifications
You must be signed in to change notification settings - Fork 667
fix #18614 RTInfo generation can fail for structs defined in imported modules #21812
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
Conversation
…orted modules allow RTInfo to be generated from the glue layer as similar members of the TypeInfo, e.g. xeq and xcmp. it is unnecessary to skip deprecated structs, as Scope's STC.deprecated_ takes care of muting deprecation messages.
|
Thanks for your pull request, @rainers! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.
|
| // Instantiate RTInfo!S to provide a pointer bitmap for the GC | ||
| // Don't do it in -betterC or on unused deprecated / error types | ||
| if (!ad.getRTInfo && global.params.useTypeInfo && Type.rtinfo && | ||
| (!ad.isDeprecated() || global.params.useDeprecated != DiagnosticReporting.error) && |
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.
This line is removed in the moved code as it is now unnecessary to skip deprecated structs. Scope's STC.deprecated_ takes care of muting deprecation messages.
thewilsonator
left a comment
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.
Otherwise looks good
| if (!sd.members) | ||
| return; | ||
|
|
||
| if (sd.semanticRun < PASS.semantic3done) |
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.
This should not be checked for templates only, as an incomplete TypeInfo can replace the correct one (compiled into the source modules object file) when linking.
allow RTInfo to be generated from the glue layer as similar members of the TypeInfo, e.g. xeq and xcmp.
This is simpler solution than #2480, but calling back semantic analysis from the glue layer is more of a workaround that takes advantage of the simplicity of the RTInfo template that just evaluates a __traits(getPointerBitmap).