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
TypeNameParser.Parse will always create a TypeDefOrRefSignature with IsValueType set as false for types not defined in the module passed to it.
The underlying TypeDefOrRef will have the correct value if the type is able to be resolved.
This happens because TypeDefOrRefSignature takes in IsValueType as an argument in its constructor, and TypeNameParser does not properly resolve this before it creates the signature.
TypeNameParser creates the signature before resolving the scope:
This results in the TypeDefOrRefSignature having the wrong IsValueType, while the underlying Type has the correct IsValueType as it is now able to be resolved.
This also causes an issue in SignatureComparer when comparing GenericInstanceTypeSignatures created from parsed types as IsValueType isn't correct.
Only ways I see to fix it are to either parse the type name backwards starting with the scope, or to use Type.IsValueType in TypeDefOrRefSignature instead of passing it in as an argument during creation.
EDIT: As discussed in Discord, another way of fixing it could be to delay creating the signature until after parsing the scope by storing the TypeReference and modifiers (byref, pointer, etc) to apply afterwards.
The text was updated successfully, but these errors were encountered:
puff
changed the title
TypeNameParser produces wrong signature on value types not in current module
TypeNameParser produces wrong IsValueType on value types not in current module
Nov 24, 2024
AsmResolver Version
6.0.0-beta.1
.NET Version
.NET 6.0
Operating System
Windows
Describe the Bug
TypeNameParser.Parse
will always create aTypeDefOrRefSignature
withIsValueType
set as false for types not defined in the module passed to it.The underlying
TypeDefOrRef
will have the correct value if the type is able to be resolved.This happens because
TypeDefOrRefSignature
takes inIsValueType
as an argument in its constructor, andTypeNameParser
does not properly resolve this before it creates the signature.TypeNameParser
creates the signature before resolving the scope:AsmResolver/src/AsmResolver.DotNet/Signatures/Parsing/TypeNameParser.cs
Lines 44 to 47 in f70da79
In parsing the signature, it eventually creates a
TypeReference
and callsToTypeSignature
:AsmResolver/src/AsmResolver.DotNet/Signatures/Parsing/TypeNameParser.cs
Line 277 in f70da79
This creates a new
TypeDefOrRefSignature
with the wrongIsValueType
, as theTypeReference
does not have the correct scope to resolve it.Only after the signature was created, the scope is parsed and set:
AsmResolver/src/AsmResolver.DotNet/Signatures/Parsing/TypeNameParser.cs
Lines 49 to 57 in f70da79
This results in the
TypeDefOrRefSignature
having the wrongIsValueType
, while the underlyingType
has the correctIsValueType
as it is now able to be resolved.This also causes an issue in
SignatureComparer
when comparingGenericInstanceTypeSignature
s created from parsed types asIsValueType
isn't correct.How To Reproduce
Expected Behavior
Actual Behavior
Additional Context
Only ways I see to fix it are to either parse the type name backwards starting with the scope, or to use
Type.IsValueType
inTypeDefOrRefSignature
instead of passing it in as an argument during creation.EDIT: As discussed in Discord, another way of fixing it could be to delay creating the signature until after parsing the scope by storing the
TypeReference
and modifiers (byref, pointer, etc) to apply afterwards.The text was updated successfully, but these errors were encountered: