Types for Signatures are not sanitized #43
Comments
Clashsoft
added a commit
that referenced
this issue
Aug 25, 2020
When setting the type of an attribute, the signature for that type is now automatically computed and stored in the typeSignature property. See #43
Clashsoft
added a commit
that referenced
this issue
Aug 25, 2020
When setting the type of an attribute, the signature for that type is now automatically computed and stored in the typeSignature property. See #43
Clashsoft
added a commit
that referenced
this issue
Aug 25, 2020
The FMethod.getSignature method now utilizes the signature building mechanics of FragmentMapBuilder. See #43
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
Signatures, i.e. the keys used to replace fragments of class files, are not properly sanitized when constructed from attribute or method types.
Example
If an attribute
barhas typeMap<String, @NonNull Object>, it initially generates fragments with signatures likeclass/Foo/method/setBar(Map<String, @NonNull Object>). When parsing the generated file in the next run, the method is parsed with the (correct) signatureclass/Foo/method/setBar(Map<String,Object>)- note the lack of the annotations and the missing space after the comma. The obvious mismatch causes a second method to be generated.Solution
The solution is to sanitize the user-supplied types like
Map<String, @NonNull Object>and transform them for use in signatures, in this caseMap<String,Object>. The implementation for the method parser can be mostly reused in this regard.The text was updated successfully, but these errors were encountered: