Place member attributes on methods and variables instead of class

[luizgustavo09]

Description

Fixes #211

Member attributes like @available, @objc, and @discardableResult are now placed on methods and variables instead of the mock class.

Changes

• Added attributes field to MethodModel and VariableModel
• Updated parsers to capture and pass member attributes
• Modified templates to render @available above and any other inline
• Updated test fixtures

Testing

• All 129 tests passing
• Added MemberAttributeTests covering attributes on methods and variables

[fummicc1]

Thank you for the PR! I left a comment.

Please let me request a review to other collaborators. I'm not fully familiar with the current specifications related to this change.

[sidepelican]

It's better than before.

[sidepelican]

Why were only these three chosen?

If using filters, you'll need to cover all combinations of Model types and attributes.

[luizgustavo09]

It's the same discussed here

We're thinking about we don't need to filter because there's no use case where the attribute should be on class scope

[luizgustavo09]

I'm not filtering anymore, assuming the every attribute must be nested with the method/var

[sidepelican]

It would be endless to add processing for each attribute individually.

[luizgustavo09]

I agree, but the problem is that the @available attribute is usually above the method/variable, etc.
@objc, @discardableResult remains in line with the declaration.

What is your suggestion for these cases? Could we handle only the @available attribute?

[luizgustavo09]

changed to handle only @available, I don't remember if swift has another use case where the attribute stay above

[luizgustavo09]

Question:
Some tests like this
protocol NonSimpleFuncs { @discardableResult func returnSelf() -> Self }

was expecting this
func returnSelf() -> Self {...
without the attribute. But imo the result must be @discardableResult func returnSelf() -> Self

[sidepelican]

Actually, @available cannot be used for stored properties.

The following code won't compile, right?

struct S {
    @available(macOS 99, *) // stored properties cannot be marked potentially unavailable with '@available'
    var a: Int
}

[sidepelican]

#330 (comment)

But imo the result must be @discardableResult func returnSelf() -> Self

This is something I'm fine with either way.
The functions correctly when the mock class used generically.