Fix: Place @available attributes on methods instead of class #327
Conversation
|
|
luizgustavo09
force-pushed
the
fix-available-on-function
branch
from
38026ec to
70d7fc3
Compare
| if isNonInitMethod { | ||
| // For non-init methods, only add non-@available attributes to class | ||
| if !attrDesc.contains("@available") { | ||
| attributeList.append(attrDesc) | ||
| } | ||
| } else { | ||
| // For vars, inits, etc., add all attributes to class | ||
| attributeList.append(attrDesc) | ||
| } |
There was a problem hiding this comment.
This approach is dedicated to @available attribute.
Please consider other attributes like discardableResult and objc.
I believe other models like VariableModel should also inherit attribute from corresponding mockable's members.
(I am not familiar with current specification around attributes; why attributes of property or method are consolidated to that of class.)
There was a problem hiding this comment.
Yeah, that makes sense. I'll extend the implementation to cover these scenarios. Thanks for the review.
If you have another one scenario not covered feel free to comment
There was a problem hiding this comment.
I just opened a new pr, could you look that one?
756faef
|
There are too many issues. |
4 participants
Description
Fixes #325 #211
When generating mocks for protocols with methods that have
@availableattributes, mockolo was incorrectly placing the@availableon the entire mock class instead of on the specific method.Changes
attributesfield toMethodModelto store method-level attributesMethodTemplateto render@availableattributes above each methodSwiftSyntaxExtensionsto filter out@availablefrom non-init methods when collecting class-level attributes@availableon variables and initializers (remain on class since I'm not sure where they should be)Testing