You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 12, 2024. It is now read-only.
The swift type Foundation.OperatingSystemVersion comes through demangling as a typealias with the name __C.NSOperatingSystemVersion.
This is puzzling on a number of fronts.
First: in demangling, the TypeAlias only has the source type (__C.NSOperatingSystemVersion) and not the alias name.
Second: I can't find the actual declaration for Foundation.OperatingSystemVersion in the source to see how it's laid out.
Third: The TypeAlias has no underlying type category (struct? class? enum? protocol? closure?)
In the code in Swift5NodeToTLDefinition.cs in ConvertToTypeAlias, I make the assumption that the type is a struct if it starts with __C and I run it through a map to get the correct swift name. I really don't like this and doubt it will work on more general typealias types.
All of this needs to be tested better including looking at other type aliases. Maybe this is also an issue for implicitly unwrapped optionals (which are an alias for optionals?)
The text was updated successfully, but these errors were encountered:
The swift type
Foundation.OperatingSystemVersion
comes through demangling as a typealias with the name__C.NSOperatingSystemVersion
.This is puzzling on a number of fronts.
First: in demangling, the TypeAlias only has the source type (
__C.NSOperatingSystemVersion
) and not the alias name.Second: I can't find the actual declaration for
Foundation.OperatingSystemVersion
in the source to see how it's laid out.Third: The TypeAlias has no underlying type category (struct? class? enum? protocol? closure?)
In the code in
Swift5NodeToTLDefinition.cs
inConvertToTypeAlias
, I make the assumption that the type is a struct if it starts with__C
and I run it through a map to get the correct swift name. I really don't like this and doubt it will work on more general typealias types.All of this needs to be tested better including looking at other type aliases. Maybe this is also an issue for implicitly unwrapped optionals (which are an alias for optionals?)
The text was updated successfully, but these errors were encountered: