fix C compilation errors with closures and nested types #1397
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary ======= Fix a bug with hook synthesis that led to C compiler errors when using some closure procedures or `ref`s with non-top-level `object` types. Details ======= * `sighashes` now uses the symbol ID as the object representation for anonymous object/enum types and object/enum types not defined at the top-level * this means that `hashType(x) != hashType(y)` when `sameType(x, y) == false`, for object and enum types * as a consequence, unique hook procedures are used for `ref T` types that used the aforementioned types for `T` * RTTI, which is assigned to types based on type hashes, also uses unique instances per object type now Multiple same-shaped anonymous/non-top-level object types are *not* merged into a single one by the C code generator, which due to all sharing the same set of hook procedures, resulted in C compiler errors due to implicit conversions between incompatible pointer types.
zerbina
added
bug
saem
approved these changes
Aug 4, 2024
Comment on lines
+167
to
+169
| if t.sym.flags * {sfAnon, sfGenSym} != {} or | ||
| (t.kind == tyObject and t.owner.kind == skType and | ||
| tfRefsAnonObj in t.owner.typ.flags): |
There was a problem hiding this comment.
For the top level check wouldn't it make sense to check if the owning symbol is not an skModule, or would that be a problem for generic instantiations?
There was a problem hiding this comment.
Testing whether the owner is an skModule symbol wouldn't be able to detect the Nested type from tseparate_hooks1.nim (where the owner is a module symbol).
sem marks such types' symbols with the sfGenSym at the moment, so that they can be detected here. The only proper solution to this mess is getting rid of sighashes, really.
Co-authored-by: Saem Ghani <[email protected]>
|
/merge |
|
Merge requested by: @saem Contents after the first section break of the PR description has been removed and preserved below:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fix a bug with hook synthesis that led to C compiler errors when using
some closure procedures or
refs of non-top-levelobjecttype.Details
sighashesnow uses the symbol ID as the object representation foranonymous object/enum types and object/enum types not defined at the
top-level
hashType(x) != hashType(y)whensameType(x, y) == false, for object and enum typesref Ttypesthat used the aforementioned types for
Tunique instances per object type now
Multiple same-shaped anonymous/non-top-level object types are not
merged into a single one by the C code generator, which due to all
sharing the same set of hook procedures, resulted in C compiler errors
due to implicit conversions between incompatible pointer types.