-
Notifications
You must be signed in to change notification settings - Fork 623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update preferInferredTypes rule to also support converting from inferred types to explicit types, fix bugs #1658
Update preferInferredTypes rule to also support converting from inferred types to explicit types, fix bugs #1658
Conversation
…erty has optional type
4d7aaeb
to
6a9444a
Compare
Sources/Rules.swift
Outdated
// If the RHS starts with a leading dot, then we know its accessing some static member on this type. | ||
if formatter.tokens[rhsStartIndex].isOperator(".") { | ||
// Update the . token from a prefix operator to an infix operator. | ||
formatter.replaceToken(at: rhsStartIndex, with: .operator(".", .infix)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The redundantInit
rule didn't work correctly when run after the preferInferredType
rule. At first I fixed this by changing the redundantInit
rule to not check the operator type, but thinking about it more it seems better to have the preferInferredType
rule change the "."
operator from .prefix
to .infix
.
@@ -991,7 +991,7 @@ struct _Descriptors { | |||
argumentName: "doccomments", | |||
displayName: "Doc comments", | |||
help: "Preserve doc comments: \"default\" or \"preserve\".", | |||
keyPath: \.preserveSingleLineForEach, | |||
keyPath: \.preserveDocComments, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated bugfix, this OptionDescriptor
key path was wrong
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #1658 +/- ##
===========================================
+ Coverage 95.13% 95.17% +0.03%
===========================================
Files 20 20
Lines 22707 22880 +173
===========================================
+ Hits 21603 21775 +172
- Misses 1104 1105 +1 ☔ View full report in Codecov by Sentry. |
let myShape1: any ShapeStyle = .myShape | ||
|
||
// This would fail with "error: static member 'myShape' cannot be used on protocol metatype '(any ShapeStyle).Type'" | ||
// let myShape2 = (any ShapeStyle).myShape |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't detect this unless the code uses the optional existential any
syntax, so I added a note about it in the "known issues" section. Within the Airbnb codebase all existing examples of this pattern do use the any
syntax, so this is ok for us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the latest changes, you could add --preservesymbols ShapeStyle
to avoid this problem when without the existential any
syntax.
…e property's type is an existential, or if the RHS value has an infix operator
9934dff
to
2188dea
Compare
@nicklockwood, I updated the rule implementation to support both |
We may also want to rename the |
@calda thanks so much for these features and fixes, I really appreciate it. Sorry I've not had very much bandwidth to discuss the design. I'm not certain yet what the best approach is with respect to naming. I'll try to collate my thoughts and get back to you in the next few days. |
Thanks, no worries :) appreciate the merges, we can iterate on develop |
This PR renames the
preferInferredTypes
rule topropertyType
, and makes the rule support both directions of conversions. It now fully respects the--redundantType inferred/explicit/infer-locals-only
option, and can convert freely betweenand
That being said each option has various edge cases that may require manual fixes. When I ran these on Airbnb's app codebase:
inferred
had about 15-20 cases that I had to fix manually (not so bad considering we have like 2M+ LOC!)infer-locals-only
mostly only had issues with cases where we had functions that look like types (e.g.func Translation(...)
) or static members that don't return the same type. I added a--preservesymbols
option that lets you exclude any sort of type or property that has this issue, which solved most of these issues. After this it was only miscellaneous issues that were individually easy to work around.explicit
, but it seems reasonable to support it if somebody wants to use it. I expect this would be somewhat difficult, but it's definitely possible.I'd be fine with leaving the rule as-is (
preferInferredTypes
only supportinginferred
rather thanexplicit
orinfer-locals-only
) if you think theinfer-locals-only
andexplicit
options are too unreliable. I findinferred
andinfer-locals-only
definitely reliably enough for use in Airbnb's codebase / style guide.This PR also fixes other issues where the existing code would cause build failures:
For example, this compiles:
but this doesn't:
I would have posted the two changes as separate PRs, but the
propertyType
rewrite depended on the bugfixes.