-
Notifications
You must be signed in to change notification settings - Fork 117
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
[Compile Warnings As Errors] Resolve Warnings & Enable All Warnings as Errors #1016
Conversation
Warning Message: "'toLowerCase(Locale): String' is deprecated. Use lowercase() instead." Replacing 'toLowerCase(...)' with 'lowercase(...)' is the recommended action to resolve this kind of deprecated warnings.
Warning Message: "Parameter 'xyz' is never used, could be renamed to _" Renaming the parameter 'xyz' that is never used to '_' or removing it completely is the recommended action to resolve this kind of warnings.
Warning Message: "Parameter 'attrs' is never used"
Warning Message: "Type mismatch: inferred type is Xyz? but Xyz was expected"
Warning Message: "Unsafe use of a nullable receiver of type Window?"
Warning Message: "'sumBy((T) -> Int): Int' is deprecated. Use sumOf instead." Replacing 'sumBy(...)' with 'sumOf(...)' is the recommended action to resolve this kind of deprecated warnings.
Warning Message: "Name shadowed: start"
Warning Message: "The corresponding parameter in the supertype 'IAztecToolbar' is named 'keyEvent'. This may cause problems when calling this function with named arguments."
Warning Message: "Non exhaustive 'when' statements on enum will be prohibited in 1.7, add 'ADD_MEDIA_COLLAPSE', 'ADD_MEDIA_EXPAND', 'HIGHLIGHT', 'UNORDERED_LIST', 'ORDERED_LIST', 'TASK_LIST', 'INDENT', ... branches or 'else' branch instead"
Warning Message: "'getColor(Int): Int' is deprecated. Deprecated in Java" FYI: This is being suppressed instead of it being resolved since the 'minSdkVersion' is also about to be update to '24' and as such this 'Build.VERSION.SDK_INT < Build.VERSION_CODES.M' logic, along with its deprecation, will get deleted altogether.
Warning Message: "'open' has no effect in an object"
Warning Message: "Variable 'obj' initializer is redundant"
Warning Message: "Type mismatch: inferred type is Bitmap? but Bitmap was expected"
Warning Message: "Unnecessary safe call on a non-null receiver of type Bundle. This expression will have nullable type in future releases"
Warning Message: "'AndroidJUnit4' is deprecated. Deprecated in Java"
Warning Message: "Unnecessary safe call on a non-null receiver of type kotlin.collections.ArrayList<IAztecPlugin> /* = java.util.ArrayList<IAztecPlugin> */. This expression will have nullable type in future releases"
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 changes look good to me.
For full disclosure, there are a few cases where some code can be moved to the ?.let
block, such as here or here, but I don't think they are particularly important - especially for this PR. So, I deliberately avoided a line comment, but then I felt uneasy that I am not mentioning it at all 😓
Related to null-ability changes; I wonder if there are cases where it'd be better to ensure that the value we are dealing is not null
(by throwing an exception) rather than only doing the assignment if it's not null
. However, I am not familiar enough with the codebase to tell where that'd make sense without investigating each change.
I suggest waiting for another approval from someone who has more experience with the codebase. It might also be a good idea to ask the editor to be beta tested after this is merged for the extra peace of mind.
👋 @oguzkocer ! Thank you so much for the review and testing, much appreciated! 🙇 ❤️ 🥇
True, I agree, especially on those two cases you mentioned. 💯 PS: I will go ahead and make the change, those seems easy enough to update anyway, thank you for spotting that! 🙇
Ha, this is a good point and I was thinking the same while applying the code changes myself, as I am not sure about the implication of suppressing the nullability by ignoring it like that vs. throwing an exception instead. The reason that I went ahead by applying changes that are suppressing the nullability is that in this #982 PR @planarvoid created a while back, he followed the same pattern. As such, on every change that I did, I went back to this PR and made sure that the same change were applied here too. @planarvoid wdyt? 🤔
I agree, maybe @planarvoid can help with that extra approval too. 😊
I am shamelessly pinging @fluiddot here in case you can help with this, or at least so that you are aware what's coming in (also, the following PR should be the I'll also add it to my list of things to ask for an extra beta test of the editor on WPAndroid, after this PR is merged and when WPAndroid starts using that new version of Aztec that contain the changes. That's all what you meant Oguz, right? 🤔 |
Thanks for the ping @ParaskP7 🙇 ! I can perform a quick check in Gutenberg using this PR as a double-check, although I don't expect any issues based on the changes outlined in the PR's description 👍 . |
That would be awesome, thank you so much for the extra hand @fluiddot ! 🙇 x 💯
Famous last words... 😅 🤞 🤞 🤞 |
Yeap, that's all. Thank you @ParaskP7 🙇♂️ |
👋 @oguzkocer !
After looking at how to move some of the code to the Can you help me understand your suggestion, for example let's focus on this case here and see if we can improve it anyhow, thank you for your help! 🙏 |
I've checked this using #1017 and shared this comment. I still need further time to test this as we'd also need to bump the |
@ParaskP7 As I mentioned in my original review, I don't think this is particularly important for this PR. I just mentioned it because I feel very uneasy when I see something and don't mention it at all. In any case, below is how I would have "improved" this function, but note that, although I believe this is more Kotlin-y, there is still some personal taste involved.
I hope you find it useful. Let me know what you think! P.S: Here is the documentation I consulted to double check that my suggestion is following Kotlin conventions. Hopefully I interpreted it correctly. 🤞 |
👋 @fluiddot !
As per my response here, thank you so much for all your help, let's pick it up again after your return, this is not urgent work! 🙇 ❤️ 🙏 |
👋 @oguzkocer !
Ah got it, thank you so much for sharing the code snippet, much appreciated, I now understand what you meant! 🙏 I was trying to figure out how to refactor by still keeping the number of nesting levels the same, naively thinking that this is what you meant, a quick win. But, I now see your recommendation more clearly. The only disadvantage of doing this refactor is the levels of nesting and the fact that using 3 chained scope functions like that might increase the mental power needed to understand what is going on. Thus, I might have stopped at the below alternative to keep the nesting at level 1, but as you said, with those refactoring, there is always personal taste involved.
No matter, thanks for bouncing ideas off that and how these functions can be further improved. I recommend keeping it as is for now, without introducing more changes, just because I think it is better to keep this PR connected to this #982 PR @planarvoid created, along with its changes, and chained with this upstream #1017 PR, without including unnecessary* extra changes in between. (*) By unnecessary I don't mean that they are not valuable and welcome, I just mean that they won't do much to help with this PR's scope. |
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.
Thanks for the PR @ParaskP7 ! I won't say I'm an expert on Aztec. I think I was trying to be overly cautious in my kotlin update PR. However, these changes are looking good! The only changes would be very nitpicky matter of taste so I'm fine with leaving this as is 👍
Thank you so much for reviewing, testing and merging this @planarvoid , great stuff! 🚀 ❤️ 🥇 |
This PR resolves/suppresses all warnings for all modules and then enables all warnings as errors as the default for this project (a27076d).
Warnings Resolution List:
Warnings Suppression List:
Test
app
and see if it is working as expected.Review
@planarvoid and @danilo04 as you were also involved in #982.
Make sure strings will be translated:
strings.xml
as a part of the integration PR.